Be aware that using TTN for tracking balloons is not really that friendly to the community network, you are in effect spaming perhaps thousands of Gateways since the packets might be received by all gateways over an area of 200,000+ square miles.
What your suggesting would be difficult, its the nature of the TTN\LoRaWAN code that lots of stuff, system variables and the like, is stored in memory and there are particular setups in the LoRa device registers. Thats all going to be lost if you swap between a LoRaWAN library, such as LMIC, and a point to point LoRa library.
I did once try something similar, saving all the LoRa device registers to an array and transmiting a point to point LoRa packet which did work. However I could not re-establish the LoRaWAN service.
Having said that, I can think of a way of doing it, I have written code that allows a TTN node to recover its OTAA session state from FRAM, the purpose being to allow the node to recover, without a re-join, from a power down or watchdog processor reset. In theory you could at startup, send the point to point LoRa, recover the OTAA session from FRAM act like a LoRaWAN node and power down again.
There was a way around the tracking, in that enthusiastic listeners could listen for LoRa point to point and push the receipts into HABHUB which would track on a map. HABHUB also accepted FSKRTTY type data (which an RFM95 can send) which can be recieved by listeners (HAMs) with a suitable SSB reciever or just a low cost SDR.
But me thinks HABHUB may have just gone out of use.