Bcrypt use a configurable iteration count, so the answer to your question is: whatever you want it to be.
If the iteration count is such that one bcrypt invocation is as expensive as 10 computations of MD5, then brute-forcing the password will be 10 times more expensive with bcrypt than with MD5.
If the iteration count is such that one bcrypt invocation is as expensive as 10 millions of computations of MD5, then brute-forcing the password will be 10 million times more expensive with bcrypt than with MD5.
That's the point of having configurable slowness: you can make the function as slow as you wish. Or, more accurately, as slow as you can tolerate: indeed, a slow function is slow for everybody, attacker and defender alike.
An additional factor is that bcrypt is, by nature, quite hostile to GPU optimization; this is due to the kind of operations that are used within the algorithm. MD5 is, by comparison, very easy to implement and run efficiently on a GPU. This means that an attacker may get a substantial boost out of a GPU when cracking MD5-protected passwords; while with bcrypt he will need to use the same kind of CPU as the defender. See this answer for further details.
If we want some realistic figures: with a good GPU (off-the-shelf, a few hundreds of dollars), MD5 speed can reach, say, 10 billion instances per second (see benchmarks there; the machine which goes up to 93 billions per second contains 8 GPU). However, with bcrypt, it would be customary to crank up the iteration count so that each hashing takes 0.1s on your server. Instead of buying a GPU, the attacker will buy (or rent) a couple multi-core CPU and will be able to try, say, 100 passwords per second. With these figures, one can say that bcrypt will make the passwords 100 million times more robust than MD5.