Reversing an unconfirmed (0-confirmations) transaction is easy to do, with a supposedly 10-20% success rate, and doesn't depend at all on hashing power. Just broadcast a 2nd conflicting tx that pays a higher fee (most nodes won't re-broadcast a conflicting tx that comes in later regardless of the higher fee, but some will re-broadcast it).
But that's different from a double-spend, which is reversing a tx that already has 1+ confirmation, through a chain reorganization.
In the pilot we are just forwarding the transactions as they come. But in future we may send extra information if we receive a transaction trying to reuse already used transaction. That will help in the race condition you described: 1. wait for a transaction 2: wait some seconds if there comes an alert about other transactions trying to consume the same inputs.
That might help, but this is an issue which can be addressed after the pilot starts.
But that's different from a double-spend, which is reversing a tx that already has 1+ confirmation, through a chain reorganization.
The economics and technicalities of this are analyzed extensively in the latest Ethereum blog post https://blog.ethereum.org/2014/07/11/toward-a-12-second-bloc...