A general software defense mechanism would probably have to either intercept all memory accesses or insert code after each memory access.

In either case, extra memory accesses would be needed since checksums need to be loaded from memory. This would also make cache misses more frequent, since checksum data would evict non-checksum data from cache constantly. This would have a huge performance impact - most software contains a LOT of memory accesses.

However, it might be feasible to mitigate this in specific cases by having custom code in software that needs to be secure.

Databases often do this already (I'm more familiar with databases but I suspect filesystems probably do too). The original motivation was to provide some defense against bug reports along the lines of "your database ate my data", that turned out to be due to 3rd party code inside the same process crapping on memory, hardware errors etc.

These checksums are typically done on blocks of payload data of course, not all memory content.

ECC single bit errors are reported to the host OS (or can at least be querried). Simply counting those and alerting if they reach a high-enough rate would be a pretty decent mitigation.