I guess I misread the question there--Gavin is right that the overflow bug of August 2010 is the only time the block chain has been affected.
But in regards to the question of precedent for everybody agreeing to update their client, we do have some pretty good examples that are worth mentioning.
Take the situation with transaction fees, for example. Up until a few months ago, the Bitcoin client contained a .01 btc minimum transaction fee. In the early days this was nearly negligible, but as the exchange rate rose it started to be a pretty hefty chunk of change, especially since it was required on any transaction of less than .01 btc. Miners were allowed to include any transactions they wanted in their own blocks (and some did) but since the majority of the network would not forward transactions with insufficient fees (and the default client wouldn't even allow you to send the transaction) it was impractical for normal users to do this.
But you couldn't simply release a new client with lower minimum fees, because the transactions it produced wouldn't be forwarded by the rest of the network. This was a very similar chicken-and-egg problem to what you mention in your first paragraph. So instead of just abruptly changing the rules, an intermediate release was first made that would forward the lower-fee transactions, but not create them. Once that release obtained sufficiently wide adoption that these transactions could be used normally, a second release added the ability to actually send the transactions, and everything worked like clockwork. The same one-two model of compatibility-breaking releases could be used for virtually any needed change to the client: first release a version that supports the change passively, and wait to see if it achieves sufficient adoption. If it does, release the version that makes the change live.
For emergency situations, however, the overflow bug of August 2010 is an excellent model. An exploit was found that allowed someone to insert a fraudulent transaction into the block chain itself, so obviously any future versions had to disregard that version of events. The previous versions, meanwhile, would (accurately) view this disregarding as an attempt to fork the block chain. You can view a more detailed overview of that incident here. The exploit was noticed almost immediately, publicised, and a fix was written within hours. The vast majority of users updated their clients very quickly(especially the miners, vital to making the new fork succeed), and the new block chain fork quickly surpassed the old--bringing all the valid transactions from before with it. And disaster was averted in clockwork fashion (there were a lot more than just a few dozen people using Bitcoin by this point).
So we end up with some pretty clear precedents for both malicious action that requires an immediate response; and adjustments to the quality and usability of the network that require consensus. I'd say the idea that people can simply agree to update their client if a change is needed has a pretty firm footing.
