Save expansion shouldn’t be necessary for expanding the character table. Actually, I think the character table already has 0xFF entries because Wall and Snag occupy the last slots, though I haven’t looked at the vanilla character table in a while. Mine is repointed and has worked just fine without save expansion.
If you’re wanting extra supports, don’t mind my self shill of my Support Rework, but it’s probably not what you want and not very compatible with FEB. My point is the only reason this drastically changes how supports are handled is that it stores character IDs instead of using a support reference table. Thus, changing vanilla system to handle more would be really hard due to RAM character data size limitations. (The link Pikmin posted goes into this in detail.)
For the class table, there’s a patch you need to use to expand it on top of repointing it. There are issues with FEB’s version of this seems to have issues, but this one is updated to have no ill side effects.
When I say repointing I mean moving the table to a new location because the old table doesn’t have enough space allocated for it. You copy the old table and copy it to free space, then you find all pointers to the old table and change them to the new table. Luckily for you, FEBuiler’s “Extended List” feature automates this for you.
When you say memory, I assume you mean ROM. RAM is probably more heretical than ROM. 
There isn’t much restriction on where things are placed in memory (with the exception of functions within bl range of one another, but that’s an ASM thing). The memory you see is entirely dependent on what it’s designed to be interpreted as. There’s a lot of documentation out there but here’s a glimpse of what one could consider “mapping the ROM” with logged functions and data (credit @StanH doc). Probably too much info, but you can look up offsets if you’re curious.
By the way, if you have any specific questions or bugs, hop on the Discord server. Just about all of us are on there ready to answer questions.