I know that content compression can cause SSL to be vulnerable to the CRIME attack, via changes in the content length when injected plaintext matches existing content. Does this principle carry over to NTFS file compression on volumes that are encrypted via tools like BitLocker or TrueCrypt?
According to this blog message, NTFS compression is per-file: it can be activated on each file individually, or on the whole volume, but even in the latter case, each file is compressed independently of the others. This makes sense because data redundancies are often intra-files, not inter-files, and doing otherwise would be quite hard anyway.
CRIME-like attacks work when the attacker can insert his own data which is compressed along with data that the attacker wishes to guess (in the case of CRIME, the secret data was an HTTP Cookie in a request where the attacker gets to choose the target path). To transfer that to NTFS compression, you must imagine a system with files that the attacker cannot read, containing data which is interesting to the attacker, but such that the attacker can insert some contents of its own in the file.
Also, CRIME-like attacks require that the attacker can observe the compressed size. I am not sure that Windows offers an access to that information, and, crucially, can yield this information for files which the attacker cannot read. To some extent, the attacker can observe the free space total count on the volume, and thus guess the efficiency of compression on a single write, but with a high granularity (that of a cluster, i.e. a few kilobytes). If the compressed size of the target files can be observed with byte granularity by the attacker, then I deem CRIME-like attacks a plausible thing.
For instance, imagine a file containing unencrypted user passwords, and user-chosen "display names". By registering new users with crafted names, the attacker would try to exploit similarities between the crafted names, and the passwords of the other users.