GPS for Cubesats - is 8km/sec too fast for consumer chips?

I would not advise to use an integrated GPS solution (containing MCU and closed source firmware) for a satellite application. There are several reasons why this might fail to work:

1. The frontend frequency plan might be optimized for a limited doppler range. Typically, the RF frontend will mix down the signal to an IF lower than 10MHz (higher IF will require higher sampling rate and consume more energy). This IF is not arbitrarily choosen! The quotient IF/samplerate should be nonharmonic for the whole doppler range to avoid spurious tones from a/d-truncation errors in the sampled signal. You may observe beating effects, that make the signal unusable at some doppler rates.
2. The digital domain correlator needs to reproduce a replica of the carrier and the C/A code at the correct rate, including doppler effects. It uses DCOs (digital controlled oscillators) to pace carrier and code generation, that are tuned via configuration registers from the MCU. The bit-width of these registers may be constrained to the doppler range expected for a ground based receiver, making it impossible to tune the channel to the signal if you are traveling too fast.
3. Firmware will have to do a cold acquisition if no position/time estimate is available. It will search doppler frequency bins and code phases to find a signal. The search range will be restricted to the range expected for a ground based user.
4. Firmware will typically use kalman filtering for position solutions. This involves a model of receiver position/velocity/acceleration. While acceleration will not be a concern for a satellite, the model will fail for velocity, if the firmware is not adapted for in-orbit use.

All of these issues can be addressed, if you use a freely programmable frontend and correlator with a custom firmware. You may, f.e. look at Piksy.

Some folks implement COCOM as an or, others as an and. Either way, for qualified customers under EAR or ITAR, vendors will happily sell you a firmware option for $$$ that disables that functionality. Hardware is identical.

Outside of that hard limitation, it becomes a RF communications problem, along with designing your hardware to tolerate radiation effects. Your Eb/N0 will probably be somewhat better as you are (literally) closer to the SVs and avoiding the atmospheric path-loss, but your receive circuitry is also going to need to tolerate a considerable amount of Doppler.

It's not just position though that CubeSats are interested in, by the way -- GPS time is a valuable data commodity that helps a satellite figure out where it is, given a TLE. Even if the receiver refuses to give you a position due to COCOM, if it gives the time, that can be worth it.

It really depends on the implementation. As an example, one receiver I've worked on has a fixed-point carrier NCO frequency register in each correlator channel, with a width of 17 bits. The maximum value that can be stored in this register corresponds to around 6 km/s, and also has to include a contribution from receiver clock frequency error. So it wouldn't be able to track any satellites whose range rate exceeds that limit, which would be quite a lot of them if the receiver is moving at orbital speeds.