From a quality perspective, sure, using a cryptographic hash might demonstrate that the large file you downloaded did or didn't get finish properly, but so could its file size.
Suppose, by either a man-in-the-middle or full-on rooting of the webserver (either will work: one is on the fly while the other is more permanent), that I can replace a generally benevolent binary file with something malicious. If I can do that, what is to stop me from generating a proper (take your pick) SHA-1 or MD5 hash and replacing the good hash on the web page with my bad one? The hash does not tell you anything. If the adversary can tamper and replace one, she could certainly tamper and replace the other.
If you are worried about quality only and not so much about chain-of-custody or tampering, you might as well just place the file size in bytes on the web page. If you are worried about tampering, use a digital signature of some sort (any PKC is better than none) so that the end-user can establish some sort of non-repudiation.
And keep in mind that:
A) You are trusting your computer to do the crypto (you're not doing it in your head),
B) Digital signatures can be used in trust decisions, but they do not automatically indicate trustworthiness (i.e. they do not necessarily indicate the author's intentions).
This is an excellent quote from Bruce Schneier on the subject of hashes/signatures:
"The problem is that while a digital signature authenticates the document up to the point of the signing computer, it doesn't authenticate the link between that computer and Alice. This is a subtle point. For years, I would explain the mathematics of digital signatures with sentences like: 'The signer computes a digital signature of message m by computing m^e mod n.' This is complete nonsense. I have digitally signed thousands of electronic documents, and I have never computed m^e mod n in my entire life. My computer makes that calculation. I am not signing anything; my computer is."