I am not a security expert. Take all my advice with a handful of salt, where the size of the hand various with the amount of security desired.
I believe this to be the case, but am not an expert on TrueCrypt. Of course, you need the rescue disk available to boot the computer, so if an attacker finds that, they can still attempt to brute force the password.
Although that is one of the goals of TrueCrypt (see the second point on their Plausible Deniability page), I'm not sure this would be plausible, for two reasons. The first is that if you merely remove the bootloader and do not replace it with random data, then there's obviously something going on. Perhaps the CD replaces the bootloader with random data, so this is not an issue; if not, it would be possible to replace it with random data in a different way. The second issue is that you do need to keep the TrueCrypt CD near your computer, so you can still boot the computer. This might limit plausible deniability. A way around this might be to have the DBAN CD inside the computer at all times, except when booting, and to have the TrueCrypt CD nearby. Say that the hard drive previously contained a TrueCrypt volume, but now does not, as you just wiped it. This is still a bit suspicious: why bother using DBAN if the data's already encrypted?
To tell if the TrueCrypt Rescue CD replaces the bootloader with random data, boot from some Linux live CD or USB drive and run the following command:
dd if=/dev/sda bs=512 count=1 | hexdump | tail
If the result is a bunch of garbage that does NOT end in 55aa, then it's random data. If it DOES end in 55aa, then it's a valid bootloader. If it is
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200
then the bootloader track was written over with zeros (I'm pretty sure you could tell that), and you need to replace it with random data yourself. This can be accomplished with
dd if=/dev/urandom of=/dev/sda bs=512 count=1
NOTE: I have NOT run this command. It may write random data to more than the bootloader, and it may make your system unbootable. Use with care! Also note that /dev/urandom is not as secure as /dev/random, but you do NOT need high-quality random data for this short sequence of bytes.
Now, run the first command to make sure that it does not end in 55aa. This is highly unlikely, but is possible, so it's best to make sure. On the extremely unlikely (1 in over 65 thousand) chance that it does, simply run the second command again.
Now, you have a completely random disk that could have been generated with DBAN. If somebody sees this disk with the DBAN disk in the machine, they will assume it's a random hard disk. They may make you follow through with your claim of installing an OS on it, but they are highly unlikely to be able to prove that there is a Truecrypt volume there.
I hope this helped, but again, I am NOT a security expert.