Generating rainbow tables is never the best way to attack a single instance. Rainbow tables are precomputed tables: you do a lot of computations in advance, under the hope that you will be able to apply these computations to several attack instances.
Precomputed tables (rainbow or not rainbow, this does not change anything here) all follow the same pattern:
During precomputations, you "try" N possible passwords and, for each of them, you apply the relevant cryptographic function (in your case, some sort of hash for password-to-key derivation, then symmetric encryption) and store the result (for a rainbow table the storage costs are lowered, but the CPU cost is unchanged -- in fact, it is somewhat enlarged due to the specifics of the rainbow).
At attack time, you look up the observed hash/ciphertext in your table. If the password was indeed one of the N that you processed during the table construction, then the attack works. Otherwise, it does not.
So generating the table costs as much as the worst case of a simple brute force attack: you still pay for hashing all N possible passwords. If you have only one instance to attack, then the direct brute force is cheaper.
In your case, you have some (unspecified) password-to-key derivation scheme h, and what you have to work with is:
f(p, IV, m) = IV xor AESh(p)(m)
where p is the password, IV is the IV, and m is the first block of the plaintext (the first 16 bytes). If you want to build a precomputed table, then that function f is what you have to evaluate for each password. The resulting table will be applicable only to cases that use the exact same IV and the exact same first block of known plaintext. If either the IV or the known plaintext is different, then not only is the table a poor idea for breaking a single instance, but it also becomes a poor idea in all generality since the table will be usable only once.
A critical point is the h function: the process by which a password is turned into an encryption key. If the h function is a proper password hashing function, the it has a salt, which is generated a new for each password, and this completely defeats precomputed tables, even if the IV and the message are reused exactly.
Even if h is a basic, fast and unsalted hash function (say, a single invocation of SHA-256), then you still cannot reuse existing (rainbow) tables, because you do not have access to the hash output; you only have the ciphertext. The encryption step is sufficient to put your context outside of the contexts for which rainbow tables already exist.
Therefore, if you want to enact your breaking attempts, you will have to implement some brute force mechanism. Roam the Web to gather implementations of AES and of the h function, whatever that hash function is. Put them together in some code that tries potential passwords. Compile, run, be patient.
In any case, such brute force works only insofar as the used password is one of the passwords that you can plausibly try within the limits of your patience. If the AES key is not really derived from a password, but was generated randomly from a cryptographically secure PRNG, then forget it. You won't brute force it.
What you can do depends on the context. For instance, if you have access to a device or system that performs encryption with the key you don't know, but on data that you can choose (a chosen-plaintext attack), then the predictability of the IV (it is always the same, in your description) allows you to perform a brute force on the data (not the key), which, depending on the data, may be very efficient.
