Entropy is a big word for a mathematical concept (in the context of cryptography), which is thus named out of an approximate analogy with the "entropy" as used in physics. Here, "n bits of entropy" means, more or less, that there are 2n possible values for the key.
For security, there is no practical difference beyond 100 bits of entropy. We want our keys to be safe from exhaustive search and this is achieved when trying out all possible keys, or at least a substantial portion of the key space, is ludicrously unfeasible with existing technology. Cryptographers have long used "80 bits" as the threshold for that; 100 bits ought to account for improvements in technology and a comfortable margin (at these sizes, energy dominates, not Moore's law). Beyond that size, exhaustive search is utterly defeated, and there is no bigger defeat than that.
Therefore, while your "128-character key" has potentially 512 bits of entropy (assuming the "characters" are hexadecimal digits) and the SHA-1 hash has "only" 160 bits (the output size of SHA-1), both are still very far into the "cannot do it" realm, and it does not make sense, from a security point of view, to say that one is "more secure" than the other. Both are immune from exhaustive search.
Correspondingly, there is no need for a salt here. Salts are about preventing parallelism and precomputations: they assume that the attacker can run an exhaustive search on one key, and will want to run the same attack on several keys. Salts ensure that the attack cost for ten keys will be ten times the cost for one key. With a 100+ bits key, the cost for one attack is way beyond what can be done, so there is little point in preventing parallelism. Said otherwise, if the salts change anything to the security situation, then the attacker is a god, and you should sacrifice oxen to appease him, not try to counter him with your puny hash functions.