Bcrypt outputs a 192-bit result, no more, no less. This is inconvenient if you want a key longer than 192 bits, e.g. a 256-bit AES key. In that situation, I recommend taking the bcrypt output and hashing it with a secure hash function with a large enough output for the required key material length (e.g. if you need a 256-bit encryption key and a 128-bit MAC key, use SHA-384 or SHA-512). Otherwise, bcrypt is considered to be fine as far as key derivation is concerned.
(Generating a 256-bit encryption key from a 192-bit value does not make much sense; but using 256-bit AES instead of 128-bit AES does not make much sense either, practically speaking. The real weakness in a bcrypt-powered system, anyway, is that the keys come from a human-remembered password; bcrypt makes such a thing tolerable, but nowhere near as secure as a truly random 128-bit key, much less a 192-bit or 256-bit key. So if you need a 256-bit key for "administrative reasons", generating that from the bcrypt output and a hash function would create no extra actual security problem.)
Bcrypt has a minor quirk in that if you split a 192-bit bcrypt output into three 64-bit values, it is mathematically guaranteed that the three 64-bit values will be distinct from each other. Thus, the output of bcrypt can be distinguished from that of a random oracle by looking at about 264 distinct bcrypt outputs (for random 192-bit values, one may expect to encounter a block collision -- two of the three 64-bit values equal to each other -- after an average of 264/3 values). This is a very slight bias which has no practical consequence for security.