This might be of interest: http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-...
So GPIO performance won't be a problem, but they note that OS multitasking can cause issues:
"What is not evident from the snapshots, however, is that due to multitasking nature of Linux, the GPIO manipulation is constantly interrupted for short periods when the CPU is doing something else, such as receiving or sending data over network, writing log files, etc"
Running on bare metal should take care of that, so the only remaining problem is how to synchronize the signal generation on the RPi with the recording of data on the host computer. (Sigh, if only RPi had a USB3 port...)
Of course that would require a Linux kernel, so not bare metal anymore, but there might be a way to make this work!
Now I just need to get my hands on one, it's out of stock everywhere within a radius of 300km...
With a few simple tweaks (isolcpus + irqbalance + setting cpu affinity), you can get rid of the overwhelming majority of interruptions a specific userland program running on a Linux machine could encounter.
If this quote is talking about kernel context switches, choice of I/O scheduler and tick rate in the kernel could be tweaked for better performance.
You can do GPIO bit-twiddling pretty fast: http://skpang.co.uk/blog/archives/323