To improve security to some extent, I use keyfile generation technique (to change an existing file into an actual keyfile).
Are you using an external tool to do that, or something built-in to TrueCrypt? AFAIK you can use any type of file as a TC keyfile, but the file is used as-is, no transformation is done. From the docs:
Note that TrueCrypt never modifies the keyfile contents. You can select more than one keyfile; the order does not matter. You can also let TrueCrypt generate a file with random content and use it as a keyfile. To do so, select Tools > Keyfile Generator.
Whatever method is used to "turn a regular file into a keyfile", you must make sure it's deterministic (i.e. always generate the same keyfile given the same input), otherwise you can't throw it away after use. And of course, if you generate it from a random source, you must keep it to be able to unlock the volume later.
If yes, then it could be safely overwritten and destroyed immediately after usage, further enhancing security associated with using truecrypt.
I don't see how that will enhance security. If the original file is sufficient to decrypt a volume, an attacker that has access to it can also do the same, regardless of how many intermediate steps there are to transform it into the resulting keyfile. Same with keyfile+password vs. original file+password. That means you have to protect this file as well as you'd do with the keyfile.
You could argue that using an arbitrary file is safer than using a "standardised" keyfile, since there are so many of them in your computer, and the attacker must know which one is the key. A 64 byte file with random data "stands out in the crowd", so they would in principle be the first ones to be tried. That's a bit like "security though obscurity", but if you have no better way to protect your keyfile, this should give you a little more protection.
However, I must point out that since TrueCrypt accepts many keyfiles at once, and it does its own hashing to combine them together and with the supplied password, you shouldn't need to perform the intermediary step yourself (that just potentially increases the attack surface).
And for a reason to have many keyfiles: if your storage media has
N files and
K of them will be used as keyfiles, the total number of combinations your attacker must try is
N! / (K! * (N-K)!). By carefully choosing this number you can make it much more difficult to brute force it, even if the attacker has access to all your files and a lot of time and resources to try them. (just make sure to scatter the keyfiles through different folders...) It's up to you to decide the tradeoff between security and convenience, since supplying all those keyfiles also has its cost - in user patience, which can be very limited.
Update: as per your comment, you're using 20 files out of 1000, which in principle would take a long time to crack (
1.6 * 10^10 years at 1000 tries/second). However, you mentioned that the files are chosen based on user input, so I must point out this fact:
Despite the large number of possibilities to choose those 20 files (
5.3 * 10^20 ~ 68 bits of entropy), not all of them are equally likely to be chosen, since the process is not random. In fact, each sequence of user inputs (lets call that a "password") will deterministically lead to a single combination. Thus, the entropy of your scheme will be at most the same as the entropy of your "password" (capped at 68 bits). In other words, an attacker that knows your process needs only to redo the same (against a list of "password" guesses) to get a viable combination of files - a better result than trying all them at random.
Also, you must make sure the logic for choosing those files does not leads to too many collisions. If two or more inputs lead to the same set of files, either of them can be used interchangeably. If that happens, the resulting entropy can be even lower than you'd get by simply using that user input as a password. And, unnecessary to say, using a password with more than 68 bits of entropy will have no effect (i.e. 11 characters or more), since at this point collisions are guaranteed to happen (contrast to the max 512 bits of entropy that you can get by using a random keyfile, or about 420 by using a random password with 64 printable ASCII chars).