It's not as simple as you'd assume and it actually wouldn't save on memory so much, unless you Incorporated loading from disk. It could save on cpu usage by reducing the amount of objects to process, but it will also take some performance to do the chunk loading. Also while it works ok for static terrain it becomes more complicated if you want stuff to be changeable. Moving objects are a big problem with this as well as they can move around and it may not be desirable to save them to a chunk.
As a simple example with only horizontal scrolling and a screen size of 640x480 you could do the following. Say you want a chunk width of 640 pixels at any given time you could have 2 of them loaded, and for example we could define the center of the chunk to be it's location.
We need to know two things: when to load a chunk and when to unload it. What can do is as the chunk gets too far left of the screen it gets unloaded and a chunk on the other side gets loaded.
set chunk x to self.x+640
Also it can be done similarly if two far to the right.
For the unloading I'd use instance variables on the objects that have the chunks id so you can pick them to destroy. For loading you'll need to store the object info in some kind of format. In the past i've used an array as json string to store the data. I'd store the values like this:
array.at(x, 0) = type
array.at(x,1) = x
array.at(x,2) = y
So to load it would loop over that array and create objects according to type. I've also done it so it's just a 1d array of dictionaries asJSON.
The chunks themselves could be stored in an array of those json strings.
I'd avoid all the above if I can. The goal should be to use less cpu. Just make the entire level in the editor. All the static objects are fine and you if you use a collision detection to pick the objects C2 has everything divided up into screen sized chunks so you can avoid processing far away stuff. Moving objects are the main issue to handle. A common thing is to disable or destroy them if they get to far from the screen.