You have the source code to TNet. You are compiling it yourself, so it works. You have Unity which comes with: exception handling and reporting (when an exception occurs it will be printed to the output window, and usually won't crash the game), profiler, and debugger. You can literally step through every CIL instruction as your game executes. You've spent two weeks fighting TNet? I don't believe you're trying hard enough, then. If you had bothered to look through the source code you could solve your problems in no time at all. Sure, Aren could noob-ify the entire TNet library and practically spoonfeed all his customers, but then people like me that use TNet as a tool instead of a full-fledged solution become inconveniced by how much unnecessary code we'd have to dig through. Perhaps that's something Aren does want to do, and I certainly can't blame him, as there seems to be a lot more noob coders than real programmers in the Unity ecosystem.
Now, I don't have TNet3 yet, so I won't be able to provide the spoon you so desire, but I'll help with what I can:
127.0.0.1 is localhost, if you send a packet to 127.0.0.1 it will never leave your motherboard. Stays within the OS. If you're hosting a server on your PC you should always connect to localhost. This isn't specific to TNet. This is networking in general.
The server writes to a few files: server.dat (or world.dat, whatever you name it), server.config (or world.config) Config/ban.txt, and Config/admin.txt. You can see this in TNGameServer::SaveTo(string fileName). I can't see an instance where the *.dat file would be written if NONE of your channels are persistent. In fact, it should be deleted. So, check that NONE of your channels are persistent, and then read the error message and stack trace if it's still failing.
You're going to need to provide more information about your RFC issue. Error messages, stack traces, code snippets. The presence (or lack) of *.dat shouldn't effect RFCs.
I'm not sure I understand what you're saying about your password test. I think you're saying you can host and connect on Android devices, but if you host on Unity editor you can't connect on Android devices. I would test the connection. Are you forwarding the ports? I would recommend not running the server within the Unity editor. Instead you should build and run, or run the standalone server. I believe you'd have to allow Unity editor through your firewall if you wish to connect to it from other devices.
A frontend should be made by the game developer... Imagine if every game had the same frontend. How crappy would that be?
No, it isn't too much to ask for a walkthrough covering the creation of a mobile networked game. It is however too much to ask for a complete spoonfed game "example".
At some point you're going to have to take a step back and decide whether you should be blaming TNet or yourself. You literally have the full, HEAVILY COMMENTED source code... Lacking experience in programming or networking is no excuse and should only motivate you to LEARN like everyone else has.
Sorry for the harsh tone, I've spent 4 days back in the unmanaged environment. Spent 31 straight hours debugging machine code. The managed environment gives you sooo much freedom, so it's agitating to hear people complaining about simple stuff.