Flip Tulipcoin, I understand exactly what you're suggesting. Thus, here's a much more specific question: how would you combat the potential for a sybil attack, without the assumption that every client must be connected to the network at all times?
How close a sibling are we talking about? Would a sibling attacker have, say, private keys known only to it's sibling? I don't mean to be circular, but how a node's "identity" is defined would be some persistent property of the node when disconnected from the network and verifiable by other nodes during the time the first node is connected. Other nodes must a recollection of the identity, such as a public key, to validate a signature exchange. Consensus of all participants validating each other on an ongoing basis with changing keys would probably be a part of it, as it would make flooding the network with confederates who would validate an attacker ineffective.
Handling failure of consensus is an implementation issue I would have to break down to use cases. If there's an overarching simple answer, I'm not seeing it.
The property of identity itself need only persist between connections, not forever. Although I dislike the SecureID system for various reasons, their implementation of object authentication requires that an object's identity be "freshened" by occasional connection to the network, it is not a static property. Now if only their token database wasn't centralized maybe they wouldn't have gotten hacked so easily this past year.