One extra layer might be helpful, but I've found that I often need more. I'm building some pretty complex levels, so the freedom of being able to add multiple parallax layers or play freely with layer ordering has been pretty helpful.
As far as how I save the levels as text objects: My levels consist of two things, a base tileset object that represents the core terrain, and then a set of 'props' with X and Y positions that represent various game objects. So in my text file, I have to store the state of the tileset, and the name and coordinates of each prop.
In general, the key to this method is creating lists in the text file using separators, and making use of the tokenat function to break up the lists again when you load. I pretty much just choose random character as the separators, but I'll explain it as best I can! Here are my saving events:
<img src="http://i.imgur.com/1B9rOEN.png" border="0" />
I originally tried to save the tileset data using the AsJSON component, but I ran into a lot of bugs and couldn't make it work consistently. I don't recommend that approach. Instead, I save the tile data for the levels by looping through each tile and saving its number, then writing them to a string as a list, with a "." separator between each one. You can see this in the setupTileString function above: It loops through each tile and appends its value to the list. This is then saved into StringToSave. Once I've done this, I add another seperator (a "|"), so I can differentiate the tile data from the prop data.
For the props, I just add each possible prop to a family and give it an instance variable that represents the props name. Then I just loop through each prop in the list and save its name, as well as its X and Y components. Each prop is separated from the other props by a "?", and the data within each prop is separated by ";". You can refer to the code above to see exactly how the string is built. Props could be anything - enemies, items, background objects, whatever you need to have directly placed. Just make sure to give each one a unique name, as this will be important in the loading. You could also add more data parameters here, if you needed to save more about a prop than just its coordinates.
Once the strings are all saved, you write them to a file using the Node-Webkit object, as I've done above. Node webkit makes it very easy to save files using the Open Save Dialog and On Save Dialog OK features. If you look at the two events above it should be pretty clear how that's being done.
In the actual game, the level files are loaded in a similar way. The strings are broken up and separated out (you can do this using the tokenat and tokencount functions), the tilesets are rebuilt, and the props are created and placed based on their names. This is all done on one layout, so I never have to worry about layering issues or mirroring my changes. You can then create your individual levels in your level editor project, saving them as separate layouts, and putting all of the actual behavior in the main game project.
Again, this may not be the best method for every game. For various reasons, it was the best fit for my game, but I only settled on it after some experimentation. Depending on how your game is structured, using a layers/layouts approach might work better for you.