You can export a device file through NFS or some other network filesystems. But the meaning of the device file is dependent on the machine where you open it. If you export
/dev/video0 over NFS from a server machine to a client machine, the client machine just sees “character device 81:0”, and interprets it as its own video capture device. The client machine doesn't even need to have the same device number assignment as the server; for example an OpenBSD client would see the same file as the pseudo-terminal driver, because that's what char 81:0 is under OpenBSD.
What you're asking for would be very nice, but also very hard. Every request on the client would have to be forwarded to the server and vice versa. There would have to be specific support in individual drivers. For example some drivers rely on shared memory between the process and the kernel, and supporting transparently across the network would be hard and prohibitively expensive in many cases. I don't know if the video capture driver does use shared memory, but given that it's likely to transfer large amounts of data asynchronously, I expect it to.
Linux has some specific support for network block devices. They do not rely on a network filesystem; the device file exists only on the client, and a daemon on the server emulates a physical block device (it might relay the operations to and from a real physical device, but often it reads and writes to an image file).
You should look for a solution that's specific to video capture. Try to run as much of the data-intensive part on the machine to which the physical device is attached. Or find a virtual machine solution that supports direct access to the physical device from inside the virtual machine (I don't know if any host/guest solution does; hypervisor-based solutions are more likely to).