This means that websites have little incentive to start supporting DNSSEC, as a MITM can spoof a DNS record simply by not including a signature.
This is incorrect. If a MITM attacker sends a result without a signature to a client that supports DNSSEC, the resolve will fail. This is because there is a signed DS record for that domain returned by the TLD's nameservers. The MITM attacker cannot also strip that record, as (s)he will then need to provide a response will a valid signed NSEC/NSEC3 record proving that the requested DS record doesn't exist. This is impossible without obtaining the TLD's (or root's) private key.
It seems that an easy solution to this would be to provide signed statements that a website does not currently support DNSSEC, similar to the way signed negative responses work for subdomains.
Is this a part of DNSSEC, and if not, why not? What other solutions are there to this problem / is it a problem?
There is no specific record responsible for domains that don't support DNSSEC. Instead, the server will prove that the DS record (which indicates the domain uses DNSSEC) doesn't exist.
One of the reasons was that for backward compatibility reasons
The EDNS specification is fully backwards compatible. As DNSSEC uses EDNS, it is also fully backwards compatible. Clients that don't support DNSSEC simply won't request (and the server won't respond with) DNSSEC signatures. These clients will not receive the benefits of DNSSEC, but will be able to query DNSSEC signed zones with no problems. The use of DS records on the root nameservers and the TLD nameservers allows for TLDs and domains to not be signed without any issues (However, such TLDs/domains will obviously not receive the benefits of DNSSEC).
