You ask about a scenario where an attacker is able to create a hash collision with an arbitrary file the attacker does not control (in this case, the valid download). This is called a Preimage attack, and is generally harder than a simple collision attack, but your scenario involves a preimage attack rather than a simple collision. Under that scenario, the following assertion does not hold:
It would be extremely improbable for an attacker to be able to generate a collision that would be a runnable program, and could somehow infect your system.
Assuming you have determined how to produce any file Y that has a hash collision with valid file X, it is likely just as easy to instead produce a working binary Z with the same hash value. Binaries have enormous degrees of freedom: you can modify embedded resources (string tables and icons and so on), metadata (program name, author, compilation date, etc.), and of course just stick the "garbage" used to produce the hash collision at the end of the file, after the real (malicious) program.
When people produce a hash collision, they aren't working from a pristine state in which there is no hash, carefully crafting data that bit by bit produces the desired hash (at least, not if they're using any even vaguely-modern hash algorithm). All possible inputs, including the empty string, have a valid hash digest. The goal of the collision-seeker is to find an input that produces the desired output, but there's no reason the input can't be partially a blob of fixed data (such as a malware program). Yes, that blob will have its own initial hash value (digest)... but so does the empty string!
So yes, if arbitrary blob A by itself produces the desired collision, blob A by itself (as a file) is extremely unlikely to be a meaningful, much less malicious, program. However, the amount of work it takes to find blob A is the same amount as it takes to find blob B that, when concatenated on the end of fixed malicious program M, the digest of M+B produces the collision.
Now, with that said, the collisions found thus far on SHA1 are not preimages. That is, the security researchers found two arbitrary blobs A and B that have the same SHA1 digest, but did not demonstrate the ability to, for a specified file X (or specified digest D, where presumably D = SHA1(X) for some X), produce a file Y that has the same SHA1 digest D as X. They produced a collision, but not a preimage attack.
Collision resistance is a characteristic of a secure hash function, so finding any collision has cast doubt on the overall security of SHA1. However, we're some ways yet from being able to produce preimage attacks (against either arbitrary digests or arbitrary files) against SHA1.