I looked into using a TAP interface (TUN is IP p2p only). The biggest issue is that it is a virtual Ethernet interface, which AppleTalk deals with in a very different manner vs. LocalTalk. You'd have to add the following to your driver, which is a bit of work:
-Build a ELAP-to-LLAP packet translation bridge. This would convert the AppleTalk SNAP DDP packets to/from LocalTalk DDP packets. It goes without saying that you would have to filter out all non-AppleTalk packets going to the interface.
-Handle Ethernet AARP requests. This would be how the virtual interface gets/sets its network and node ID. Thing is you have to be careful with all this since LocalTalk is a non-extended network (only one network number).
I can see why LocalTalk was implemented the way it was in the Linux AppleTalk stack. They basically bypass the AARP probe when a LocalTalk interface is detected and pass whatever node number the interface auto acquired. The DDP packet handling code also has a LocalTalk specific mode.
TL;DR: Yes it can be done in userspace.
GSPort does it to allow an emulated Apple IIgs to access AppleTalk resources on Ethernet. No, it is NOT easy, particularly when you have a kernel AppleTalk stack that only makes assumptions that it is running on a Phase 2 EtherTalk network and thinks it's talking to an Ethernet card. I don't know how well versed the kernel mailing list folks are on AppleTalk in general. I'm betting they don't know that LocalTalk is VERY different from Ethernet when it comes to the data and network layers.
Even the GSPort example may not work as-is in this case. That senario is a LocalTalk client on an Ethernet network. The bridge handles the AARP requests on behalf of the client and some workarounds are done on the LocalTalk side with node address assignment. This would be the opposite (Ethernet on a LocalTalk network).