Nice try. It really depends on the two coverage areas and wireless client implementation.
If there's a gap where there's no signal between the two access points, almost any client will properly start hunting for the a better connection.
If there's some overlap between the two coverage areas, then the client will start to hunt for a better connection as soon as the signal from the original access points disappears.
Where it screws up is there's substantial overlapping coverage between two access points. For example, putting both access points in the same room will cause the client to select one of them and hang onto it forever.
The client also plays a bit part in the puzzle. Some implementations will hang onto a weak connection long past the point where it should have given up and started hunting for a better access point. The idea is that for moving clients (i.e. mobiles, PDA's and VoIP phones) one would want to extend the dropout time so that the connection doesn't timeout and disconnect. Such long disconnect delays are also helpful in dealing with intermittent interference, where one would want to recover the original connection after the interference disappears.
On the other foot, there are clients that will disconnect and switch at the slightest provocation or signal loss. Intel keeps optimizing (juggling) this timeout in various versions of their Proset Centrino drivers. It makes roaming easy, but is hell on maintaining a connection while moving.
There's no optimum answer. Methinks client software vendors should give the customer the option of tinkering with the disconnect timeout, but everyone seems to be waiting for 802.11r which will allegedly fix the fast roaming problem, mostly for VoIP applications.
Removing the antennas created the "gap" I described in my first scenario above.