Yes, N9 does support LLCP (both connectionless and connection-oriented); application developers can use the Qt Mobility API to create LLCP servers and clients.

There is no restriction to how much data you can transfer over LLCP; as long as you keep the two devices together data can flow between the two. For a keyboard you'd need an app to convert from data coming over LLCP to keyboard events at some suitable level (X? kernel? something else? dunno)

For anyone interested in LLCP, have a look at the NFC Forum LLCP and NFC-DEP specs, as well as the Qt Mobility NFC API LLCP socket documentation.

However, LLCP is just a communication protocol -- from an application point of view "LLCP support" is about the same as saying that N9 supports TCP and UDP -- necessary but useless by itself. You have to have some application protcol talking on top of LLCP to get any use out of it.

There's also the issue of latency. The LLCP p2p operation is asymmetric, one device is a master while the other one is a slave, and the slave cannot send data except as a response to a PDU from the master. For the cases where the master doesn't have anything to send it sends empty frames to which the slave can reply with data, but I can't now recall what is the default interval for N9 implementation. (it is trivial to make a LLCP "ping" application and I have made one in the past, but I don't currently have two devices so I can't make any measurements now). Dunno what kind of latencies would make keyboard use irritating, but I guess we're talking a couple hundred milliseconds at most.

I won't comment on the battery claims, because I don't have any real understanding on the radio side of matters. NFC tags work only on the current induced from the active device's signal, but I can't say if it would be possible to make a p2p device acting always in the target (slave) role without a power source. I'll leave that to someone else