How would one go about defending against this sort of attack to best protect a sloppy user? There can be obvious signs of a spoofing attack, such as not using SSL, slightly different domain, etc, but I am assuming Tristed.com (the malicious site) has completely fooled the user. The only mitigation that comes to mind is having automation prevention built in, like Captcha. I don't know if I am completely missing something here, so apologies in advance. I have abstracted a lot of detail for the sake of keeping the diagram simple.
What you are describing is basically a user that enters his credentials on a malicious site that appears to be a trusted site. Those credentials are used afterwards to compromise the account of the user.
You are totally out of the loop until the credentials are misused, so there is no direct technical measure you can set. Even the CAPTCHA you proposed to protect against automated misuse afterwards does not work, because this CAPTCHA can be forwarded to the tricked user as well.
This means your best approach is educating your users, how to identify malicious sites. One good measure to suggest is bookmarking the site instead of searching for it. This would eliminate future mistakes, as long as the bookmark is used.
In addition, you can monitor to identify fraud scenarios and react fast to mitigate damage. In case the attacker is sloppy and uses a single IP address to access the real site, you can detect many different users coming from the same IP, which might be an indicator of such an attack. Please note that a larger network behind a NAT would look the same, so be careful with countermeasures.
If you have control over the user environment (e.g. they are clients on your corporate network), you can enforce client side protection mechanisms. I assume you are talking about outside users though, because they use a search engine to find the site, so I won't go into details concerning client side measures.
A good security measure for this is having a navigation proxy in place that block suspicious websites.
In this case maybe tristed.com have been created recently or is unclassified or directly suspicious and a navigation proxy may block or alert against it.
Similarly may be a DNS solution may find the URL suspicious and block it by resolving to a sinkhole IP.
You can use webauthn in order to get different responses to a challenge from tristed.com, which could not be used on trusted.com.
This is however linked to a specific device or OS account. You thus need the user to either have a compatible hardware component, or have them be able to only use the account on linked OS accounts (though I have only used the hardware device so don't know how easy to use the system is without one).