"Time-Memory Trade-Off" is the generic terminology for an algorithm which improves (shorten) running time by using more space (memory); or, similarly, that improves memory usage (i.e using less RAM or disk, or using it "better", e.g. with sequential access instead of random access) at the expense of more computing time.
In the case of password hashing, the main TMTO algorithm is due to Hellman back in 1980; a number of local improvements were later discovered, resulting in what is colloquially known as rainbow tables. We can get a conceptual view of rainbow tables by considering the two endpoints of the spectrum:
Exhaustive search is about trying all potential passwords, hashing them all and comparing the value with the one that is to be cracked. This has the highest computational cost (average N/2 hashes to compute for N potential passwords with uniform probability) but uses only negligible RAM.
A precomputed table contains the hashes of N potential passwords, and a single lookup needs to be done. We don't count the effort of building the table because it can presumably be reused for multiple attacks, possibly by multiple attackers. The size of the table is proportional to N, but the computational effort is negligible (well, about O(log N), which is small).
Rainbow tables will fit in between. When the table is built, you choose a parameter t called the "average chain length". The table size will be proportional to N/t: it is reduced by a factor of t, compared to the precomputed table. On the other hand, each attack will imply a computational effort proportional to t2 hash computations, and t lookups. Depending on the operational conditions, the lookups or the computations will be the bottleneck (e.g. it depends a lot on whether the table are in RAM, on a SSD, or on a set of mechanical hard disks).
Salts completely thwart precomputed tables, including rainbow tables. Building a precomputed table for N passwords has cost N; building a rainbow table for the same N passwords has even higher cost (about 1.7*N). This is worth the effort only if the table can be used at least twice, to attack two distinct hash values; a one-shot table (rainbow or not) is not competitive with exhaustive search. But the point of salts is that there is not one function; in fact, there is a big family of functions, and the salt value tells you which one is actually used. A table built for a specific salt has absolutely no value in breaking a hash value for any other salt.
Bcrypt uses salts, so no tables, and no TMTO. Attackers are back to exhaustive search. Bcrypt also has weapons against exhaustive searches, namely a configurable slowness, obtained through a huge number of internal iterations: from the user point of view, there is not much a difference between a hash computation which takes 1 microsecond, and one which takes 100 milliseconds; but for the attacker, the latter means 100000 times the effort for his exhaustive search.
See this answer for more on secure password hashing. Short summary: if your password is strong (i.e. has high entropy), then even powerful agencies won't be able to obtain it by breaking the bcrypt hash upfront (they'll get it by breaking your kneecaps, but that's another story).