It can simply stop the connection and show the user, under the normal certificate, a message telling him there's a problem with the cert.
But remember like I said that's just one example of why it's a bad idea, there's others, e.g. what do you do about EV-SSL certificates? You can't fake the browser element for them (remember this is the case where the A-V product hasn't hooked the browser), so where you want to MITM a EV-SSL connection you have to downgrade it to Non-EV.
Also what do you do with certificate pinning (either browser in-built or HPKP headers?)
Consider the goals that are trying to be achieved. You're attempting to stop the user either downloading malicious content or perhaps getting hit with a browser exploit or possibly you're trying to stop users going to a "bad" site.
The first one can be covered off with traditional on-access scanning of files.
The second one is much better addressed by improvements in browser sandboxing or general app. security.
The third one can be handled at a DNS level with reputation based block lists.
And, rolling back around to the main topic, preventing internal machines from being compromised by viruses, since a lot of people end up having to hit at least one website of some sort that has at least one tracking or advertising widget that could by three layers of indirection get compromised to serve viruses, which is, alas, not some sort of far out scenario nowadays, but just another day of the week on the web. (That is, even perfectly safe browsing habits can still get you owned on the modern web. And saying that a modern network can't count on "firewalls" and must have defense in depth still doesn't mean it's just peachy keen if an internal machine gets compromised.)
If you're going to insist those corporations can't penetrate HTTPS for compliance and security reasons, you're going to have to be willing to lift those restrictions and deal with it when their security fails. There's no two ways about this; either you grant them the necessary tools for compliance and security, or you stop complaining when they can't comply and aren't secure. (And at scale, let's be honest; the latter isn't on the table.)
The advantage is that they should have informed professional security people who can understand the trade-offs and make intelligent decisions about them.
Even then this strategy fails against certificate pinning which is becoming ever more common in mobile and also web space, so corps need other solutions to those problems (likely endpoint based)
However what we're talking about here is end-user A-V products and their use of HTTPS interception at a desktop level and the trade-offs that this forces on individual end users who are less equipped to handle this.
Realistically the A-V product will likely choose to cause "less noise" to the user so won't present them detailed technical information about the errors their masking, potentially making the user's security worse.