There are two different issues that we need to separate:
User confusion due to accidental hash collision is indeed something that we worry about, although it should be rare and improbable. If the user tries to do an action whose signature is the same as some other, then it means that the app will either not be able to decode their data on the confirmation window, or if it can, show the wrong function. It's rare and easily avoidable by the app developer if they want. The interface can deal with this by trying multiple hash collisions to see which one is able to decode the whole message, or by simply setting them by the contract byte code.
Possible phishing attempt due to hash collision is something that seems very implausible to me. It's important to note that the function name is set by the contract code, which can do whatever it wants regardless of the function name. During a transaction confirmation, it doesn't really matter if the function name is
killAllPuppies, what matters is what the contract itself does, and that's what the interface should worry about. So anyone building interfaces for ethereum should have all sorts of tools to defend users from scams: whitelists, blacklists, flags if the code is not open, stamps claiming the code has been audited etc, and more importantly making sure that the contract you are interacting with is the one you believe to be. If a scammer wants to fool users with an evil contract, they don't need to worry about finding collisions, they can just use the name they want.