The problem itself is not Bitcoin-specific per se. It's a matter of being able to verify the sender of some data. Bitcoin addresses are only designed to be immune to typos (they contain a checksum), but otherwise the protocol does nothing.

One can, however, do a couple things to make sure a proper address is sent and received:

• One can use a vanity address that is hard to generate and clearly is related to the situation. Using 1Bob... would not be the best choice, but 1BobEveryman..., or 1ThankYouAlice... can be better (examples chosen for clarity, normally you'd be using base 58 alphabet). Generally, if it takes more than a couple minutes to generate an address you know it either came from the original sender, or someone deliberately wanted to steal Bob's identity (by spending a lot of time beforehand generating the address).
• One can try checking the history of the address in the Bitcoin Block Explorer. If the address has been used a couple times, it is less likely it will be fake. Being Eve I probably wouldn't want to use the same address for scamming people more than once, and generating a history of transactions would take some time.
• One can ask Bob to provide his Bitcoin address wrapped in Bob's digital signature. The main problem with this is securing Bob's signature in the first place, which is basically the same problem as we are solving right now.
• One can look for address received on the internet. A lot of people have a habit of including the Bitcoin address they use in places like forum signatures, their websites and the like.
• If Alice knows Bob, they might decide on using some information only they would know to create an ECDSA keypair and use that for transmitting Bitcoins. Such information might be for example be the movie they saw when they first met, some information from the school they attended and so forth. Generally, something that they remember and would be hard to find out. Alice can use that as the private seed of the keypair, generate the public address to send the Bitcoins to, and make the transfer. Bob then would have to repeat the same process and withdraw Bitcoins on their end. The main problem with this approach is whether Bob an Alice know each other beforehand and trust themselves with handling private keys.
• When all else fails, one can always meet Bob in person and get their address that way.

All in all, there are many ways to prevent a man in the middle attack in the descried scenario.

The #bitcoin-otc marketplace uses GPG authentication to protect against this very situation.

Because irc nicknames are vulnerable to manipulation, the task of first authenticating with the channel's bot helps to ensure that the communications are truly from the intended trading partner.

• http://wiki.bitcoin-otc.com/wiki/OTC_Rating_System

This is just one method to address this subject. There are many options.

If Alice met Bob through his website, https://bobbysox.com/, then she can be pretty sure that the address Bob displays on his site is real, so long as Bob's SSL certificate is verified successfully. For Eve to play woman-in-the-middle she would have to somehow get hold of a certificate for bobbysox.com, or Alice's browser will alert her to the fact that there's a problem with the secure connection. (Whether Alice takes any notice is another matter).

That's often how Bitcoin addresses are passed from merchant to buyer, via secure socket layer web connections.

Note: interestingly, when I click on that link I just made up, I see a warning: "The site's security certificate is not trusted!"