I knew a really bright guy when I worked at Apple that had a bad simm and he was too lazy to order a new one, so he only ran a throwaway program over that address.
Over time, he noticed from the debugger that all the crashes were at the same address.
The problem here is, I doubt you want to be running Mac OS 7.5. But the general theory is this:
If you knew a lot about the hardware and the OS, you could probably script something at boot that would run two processes, one that eats up all the memory just before the bad hardware address, and then one that sits on the bad range.
The real problem is if it does crash, you need to find a way to re-squat on the space, or you will launch something important on it eventually.
In classic Mac OS, that was pretty easy to do, because the allocation was basically contiguous hardware memory blocks..
If you could suppress access to the process, (the equivalent of a kill -SIGSTOP), and HOPE that the system doesn't access the memory. Operating systems are so much more sophisticated with memory management now.
It also depends on whether the old memory causes a crash or the entire system to seize up. I don't really know enough about memory systems to say what the probabilities are.
And I freely admit: I'd never do this myself, I'm just posting because you asked.