The risk with a backdoored TREZOR is not that it generates public/private keys incorrectly (which is what the BIP32 test vectors test). It's that it can leak the private keys/seed via some side channel, or can be told to sign transactions bypassing the usual user confirmation logic.
For leaking private keys via side channels, there are virtually none available, except the ECDSA k value. Deterministic ECDSA is the solution to this. A backdoor that allows the computer to tell the device to empty itself out cannot really be defended against easily, because it's hard to know what software the device is truly running, but the reputation of the creators is sufficient to give good assurance for genuine/unmodified TREZORs. In future software remote attestation techniques might be interesting.
Well, one of my fears (perhaps unfounded) is that a tampered device will ignore my randomly generated input seed, and instead use some kind of weak method for generating the master private key. If all of the algorithms are published however, I should be able to test whether the device is using the input seed as intended right? (i.e., compare the master public key generated on my laptop using the same algorithm as the public key generated by the trezor, where both used the same input seed).
Just to clarify, when I say "seed" what I really mean is the random data (dice rolls or whatever) that are used as a source of entropy.
