There is no theoretical limit to the number of bits per second in FSK but in practical terms, the faster the bit stream the harder it becomes to extract the bits afterwards. The problem is that to know which of the two frequencies the bit represents, it has to be found by detecting how many cycles of the frequency lie between the bit edges.
Example at low bit rate:
suppose a '0' (zero) is represented by 1KHz and a '1' is represented by 2KHz, your bit rate is 10 bits per second.
So one bit is 1/10 second.
If that bit was a zero, during the bit period there would be 100 cycles.
if that bit was a '1', during the bit period there would be 200 cycles.
Example at higher bit rate:
Same frequency but now at 1000 bits per second.
If that bit was a zero, during the bit period there would be 1 cycle.
if that bit was a '1', during the bit period there would be 2 cycles.
Even higher bit rate:
Same frequency but now at 1,000,000 bits per second
If that bit was a zero, during the bit period there would be 0.001 cycle.
if that bit was a '1', during the bit period there would be 0.002 cycles.
Detecting the difference between 100 and 200 is easy, it gets more difficult to tell when there is only 1 cycle difference and it becomes almost impossible when there is only 0.001 of a cycle difference. You can get around the problem by increasing the frequency so there are more cycles per bit but then then handling the frequency and timing the cycles becomes more problematic.
You question mentioned 100 Mb/s, if you make an assumption that it takes at least two cycles to make a reliable difference to measure you can see you are quickly heading towards Gigabit bandwidth and sub-nanosecond timing measurements.
Such things are possible but extremely difficult and expensive to implement, that's why FSK is not normally used at very high data rates.
Brian.