A bigger issue may be the operating system on the PC itself. Unless you have significant buffering on your sampling device, you will run into delays in the PC that will cause you to lose data.
I got full 480Mbps USB bulk throughput between a USB2 micro and a linux PC application written in Python. Not even in C! It uses libusb, which I recommend. libusb allows you to initiate bulk transfers directly, without having to write a driver. It is quite simple to use.
You must use scatter-gather DMA. Good thing is, that should be the default. The idea is that you pass a list of empty buffers to libusb. These are placed into a linked list which is managed by the usb hardware itself. Every time your device sends a packet, the USB chip inside the PC grabs a free buffer from the list and fills it up. Then it periodically fires an interrupt so your app can gather the filled buffers. This process is entirely managed by hardware, it will work even if the CPU is busy, swapping, etc, as long as you give it enough free buffers. The PC's cpu does not bother to process each packet. In fact you can pass large buffers (like 64kB) and the USB hardware will pile up packets into that and ping your app when the buffer is ready for consumption.
With enough buffers, you should not get dropped packets. I didn't, and the thing ran for hours while compiling linux kernels and anything else I could throw at it. Smart DMA chipsets are remarkably smart!
Since the micro runs at 300 MHz I'm assuming it's a beast and it won't have like 1kByte of RAM. You will need to buffer a few frames' worth, so a couple tens kilobytes will be OK. Make sure you setup the embedded USB core with proper DMA, fifo, or scatter gather, whatever your chip uses, but it is important to use the most efficient mode.
If you choose Ethernet, this is basically the same. PC NICs have scatter-gather DMA so just set the socket buffer to "yuuuuge" and let the hardware do its job. You can use UDP, no need for TCP.
However Ethernet will require construction of UDP packets in your firmware which does take a little bit of time. USB2 hardware will slice data into packets for you. But Ethernet is isolated, and allows much longer cable lengths, which might come in handy.
Also Ethernet will not crash a PC. Messing with USB when your experimental USB device is buggy can do funky stuff to your PC. Your OS' drivers have only been tested on USB devices that work. So when your micro hangs between some phases of the USB transaction, notably enumeration, or sends bogus data causing the driver stack to suddenly feel an urgent need to allocate -1 bytes of memory, you can expect the PC to go "WUT?" and have to press the Windows key (ie, reset button). I use a junk laptop with no data on it.
If you worry about UDP losing packets... I left it running for a 24 hours, with two dollar store 10 meter cables and a dollar store extender in the middle, no lost packets at 100Mbps full duplex.
Hm well that was a bit of an infodump, but it should work fine. I'd be more worried about how your micro is going to sync the acquisition, don't expect to fire an interrupt every 100ns... you will need hardware and DMA for this. If you use 4 bits, you could hack the quad SPI port maybe? Or if it map a DMA port to pins...
Another solution would be a Cypress FX2LP EZ-USB micro. It has a hardware FIFO, so if you give it a clock, on every cycle it will grab 8 bits from its data pins and send this to the PC via USB2 bulk transfer. All in hardware. You need to write about a page of C code for firmware, to say hello to the PC, enumerate, and connect the hardware FIFO to the USB endpoint. You get 8 bits instead of 4 though... hey thats 4 free bits!
Anyway. Realistically, one of these should do the job.
