You guys are all missing the point (I guess none of you write software).
When someone builds a device that communicates via USB to the OS, unless it is something simple like a keyboard or a mouse, they need to write a driver that runs on the computer that recognises when its device, in your example, an iSight web cam, is connected. When it gets a message from the OS that a new device has been plugged in, and the devices hardware ID matches the device it is looking for, it can create the bridge between the camera and the computer. The driver has specific (and often proprietary) knowledge written into it to talk to that device and then either uses it itself or makes a more generic interface available to other applications.
When you buy a printer, you get drivers for that printer that talk to the printer directly and have knowledge of that printer's features and at the same time creates an entry in the OS telling it that a printer is available using a protocol defined by that OS. So the driver acts as the bridge between proprietary equipment and the OS.
For the same reasons Parallels can't write printer drivers for XYZ printer they can't write a Windows side driver for the iSight camera. If Apple were to write a driver for the camera for Windows (since Apple knows how to talk to an iSight), then it should work in Parallels. But it is not in Parallels power to write a Windows iSight USB driver (or one for the FireWire ones for that matter) any more than it is their power to write drivers for other hardware. All that they can do (and I wish they did) is provide a stable and working USB emulation so that drivers that actually do exists can work properly.
Regards,
rcomeau