Assuming you haven't somehow stolen the real site owner's private key, you would need to produce a certificate for that DNS name, signed with a key you do have.

Which is something you could in principle do if you are a trusted root CA. But, this creates a smoking gun. The bogus certificate is a public document, you're always giving it to the client, and for Chrome, Safari, Chromium Edge you are also obliged to publicly log the certificate, where everybody can see it forever, in order to have an SCT (proof of logging) which those browser insist on seeing.

Modern rules require a root CA to disclose any intermediate CAs which are created, even if not currently in use (e.g. because still being tested) and which could issue trusted certificates unless the certificate for the intermediate is technically constrained (which is complicated, but a general purpose CA is not technically constrained for the purpose of this definition)

In practice, most outfits offering "MITM" type capabilities are for corporate environments, education, that sort of thing, where you can say "All employers/ students/ whatever shall trust our our private CA FOO" and then you can MITM using the trusted FOO CA. So this doesn't interact with the Web PKI overseen by m.d.s.policy at all. If you don't want to get MITM'd don't trust some sketchy private CA.

Maybe a sufficiently crafty vendor of MITM equipment could prevent MITM site certificates that are signed by evil intermediate CAs from appearing in CT logs by filtering access to those CT logs. But it is a risky proposition for the vendor, as you've said.