2 bits isn't really a CRC... or much of anything, I think?
You need 1 bit for basic parity. You need at least 3 bits to do a sum (2^3 = 8 maximum number of bits) for example. Hamming code needs 4 bits to correct single-bit errors for 8-bit words. Or you get better efficiency for more, but I'm guessing that would suck. You wouldn't want to have to decode the entire message packet (say 32 bits worth, plus check bits) just to see where it's going.
Heh, error correcting codes are probably a bad idea anyway actually, since that's the point, it needs to be detecting errors for arbitration purposes. I mean, you can use them both ways, single-bit correcting is double-bit detecting, you can provide that as an output from the decoder.
It's kind of a weird thing anyway, regardless; you're relying on bit errors to serve a specific purpose. Which means you can't really tolerate bit errors at all. Consider if some interference is reliably causing single bit flips that trigger the arbitration function, it'd basically be trolled by it and nothing can ever get through.
Mind, that's true of the original (I2C), not specific to your proposition. It's all the more reason why I2C needs to be kept on board, well away from cables.
So anyway, if nothing else, I guess error checking on the ID/address alone, wouldn't really make sense. Some check bits or CRC at the end would be good though. And then you have good reason to use more bits, maybe a traditional CRC8, or, uh, what does I2C actually use again?..
Good luck, in any case. Looks like your proposal is more than slow enough to bit-bang, if you're so inclined, so whatever timing, byte/word/packet length, EDC and ECC you like, are all game.

As an aside, if bus-open times are symmetrical with bus-active times, I think that's basically Manchester encoding?
Tim