I think this is a great idea and I will support including it in the official client.
Apologies if I posted this already - why can't we just add a check digit instead of changing the account number to alphabetti-spaghetti, not perfect but i would catch the majority of errors.
http://en.wikipedia.org/wiki/Luhn_algorithmI was originally thinking around the same lines. I was playing around with a modified Luhn code that used a check character rather than a digit since some account numbers without a check digit would pass the Luhn check. It was easier to see that 1234567A was a checked code (for the naked account number 1234567), rather than 12345671, for example, and it could still be easily used without the check character for clients that didn't support the Luhn check.
The reason I was looking at a modified Luhn, rather than a CRC or the Verhoeff algorithm, was that the check could be calculated by hand, or mentally with a little practice.
However, with a little reflection, I think ricot's proposal is much better. It has error correction built in, which is a huge plus.
I can see the benefits of ECC but it generates something that in my humble view is even harder to get right - I've tried a few account numbers in his useful website - yes its balanced by error correction but I don't think its solving usability.