I've seen a handful of memory modules fail outright in operational servers over the last decade or so and a slightly higher number of failures when doing Memtest86 burn in tests on newly delivered hardware. These are server systems, almost all of which will have ECC memory of one sort or another so I'd expect much more frequent issues on client systems with non-error correcting RAM. I don't have a huge sample set to work from though, we have a couple of dozen servers of our own and in terms of commissioning customer systems I'd say I've worked on a hundred or so at a level where I'd actually be paying attention to the RAM.
On the client side I have a bit more experience at enterprise scale - I was a senior engineer for a group managing 50k end user PC's for a couple of years and we never saw RAM hard or soft failures as a significant problem, certainly it was not something that affected any measurable percentage of systems. That's not to say it didn't happen, just that I'd be very surprised if it was a problem that affected >1% of business class desktops and notebooks. Some specific models would demonstrate really high failure rates that were related to build quality control, the first batch of IBM Thinkpad T30's had an issue with their second DIMM slot that led to us having to repair\replace a couple of thousand machines at one point.
This blog post from Microsoft's Larry Osterman from 2005 might give a possible explanation for some of these though - his analysis of some weird errors reported in the fairly large dataset that comes from Windows Error Reporting indicates that many of those strange problems are caused by over-clocking. If a significant number of your end users are likely to be using over-clocked consumer level kit then this may be related to your errors.