As mikeazo notes, PBKDF2 supports the generation of arbitrary amounts of key data. It accomplishes this simply by appending a running counter to the salt and rerunning the key derivation process to generate new output blocks, so there's no obvious reason why you couldn't apply the same construction to bcrypt.
The scrypt KDF also supports arbitrary-length output, which is not surprising, since it's based on PBKDF2.
Ps. In PBKDF2, each block of the output is computed independently using the full iterated key derivation process. This has the disadvantage that the CPU time needed to run the KDF scales linearly with the desired output length, whereas the work of an attacker who only needs one of the output blocks doesn't. (This is not a far-fetched scenario: for example, if you generate two output blocks and use one of them as the encryption key and the other as the MAC key, an attacker only needs to generate the latter to check whether he guessed the right password.)
Given this, it would seem better to generate only one output block with PBKDF2 (using a correspondingly larger iteration count) and then use a lighter-weight KDF (or even PBKDF2 itself with a low iteration count) to expand the output to the desired length. Of course, given that this seems like such an obvious thing to do, one might wonder why PBKDF2 wasn't specified that way to begin with.
Interestingly, this also seems to be more or less how scrypt uses PBKDF2. Specifically, scrypt invokes PBKDF2 twice, both times with an iteration count of 1: first to expand the passphrase into input for the memory-hard mixing function SMix (on which the hardness of scrypt is actually based), and again to hash the output of SMix into the desired amount of key material.