Yeah, scheme sounds roughly okay. Difficulties are, you'll need to keep a buffer of the previous sent byte(s) to compare, the comparison is bitwise-logical (so there's not much data to obtain from it either -- not that there's much purpose besides "hey, this is wrong"), and... well, all the other protocol overhead that CAN involves, really.
Supposedly, CAN was developed using RS-485 drivers and support components, so their similarities are no accident.
I'm not entirely convinced CAN drivers are much or any more robust than RS-485, but it depends which ones you're looking at. A few CAN drivers are rated to survive huge overload conditions, like 70V (with transmitter off). CAN specifies a wider CM range, but I think it's also not required to necessarily receive or drive valid bits under that condition? So the +12/-7V range of RS-485 really isn't too big a deal.
If you need high CM range or rejection, you'll be much better off with a different standard, anyway. Trying to force-fit something, it can be made to work, but really just isn't suitable for it, you'll end up spending a lot of time making it work. Consider adding galvanic isolation (optos, transformer coupling), or even using fiber optics.
Note that RS-485 can be isolated fairly easily, using Ethernet transformers, a fairly high baud rate (say 1-10MHz), and Manchester encoding either by XORing with the bit clock (synchronous) or by formatting bytes into pairs of encoded nibbles (asynchronous -- you may not be able to suppress the USART's start/stop bits in the middle of those two nibbles, so adjust accordingly). Some kind of DC-balanced line coding is necessary to use coupling transformers; Manchester happens to be the simplest way to ensure that.
Tim