So to do that it's going to stop the users browsing session, redirect them to a local web page and then present something to let them make a decision about carrying on? not the best user experience in the world..
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?)
Easy, you don't tamper with HTTPS traffic, it's innately a very bad idea.
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.
That doesn't work for corporate communications, though. There are numerous use cases where a corporation must be able to penetrate HTTPS internally in order to comply with regulations, both for direct reasons such as regulations regarding corporate communications, and indirectly for things such as internal security, protection against insider threats, and a lot of other second-order issues like intrusion detection.
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.)
I know corps need to do that, and they get to handle the trade-offs that it generates (although I'd argue that HTTPS interception doesn't in any way provide a panacea for the internal security issues you've mentioned).
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.
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?)