“Roguelike maps” can mean a lot of different things. It sounds like you mean maps representing individual rooms that are then arranged procedurally in-game? (If you’re going for a more classic Rogue-like structure with irregular rooms and connecting hallways, it’s more common to not pre-build rooms at all, and do all the work procedurally, as that’s much more flexible.) In Tiled, these pre-built rooms generally work like most other maps - you build the individual rooms as maps in Tiled, marking doors, interactive elements, etc, but instead of having a fixed arrangement and connections, you determine that in-engine. To facilitate “mashing them together”, the exits are usually in standard locations and of standard sizes, but you can introduce variety by having multiple standard locations and sizes. To make the rooms more flexible, you can make some or all of the exits optional by e.g. having separate layers with doors and walls, and choosing one or the other as appropriate, or by marking the doors with Objects and spawning in the doors only when needed. It’s also common to make the rooms either all a standard size, or multiples of some standard size.
Similar to doors, you’d mark up where various entities go, e.g. where the shopkeeper is in a shop room, where a lever or key might spawn in a puzzle room. In some cases, it’s more useful to mark up entire areas in which entities (e.g. enemies) can spawn, using e.g. a Rectangle or Polygon object. How you actually do this in Tiled depends on what’s convenient for you to parse in your engine/game; I’m not familiar with Axmol so I can’t make specific suggestions. For my C++ games, I use Objects (usually Rectangles or Tile Objects) to define elements that aren’t just purely cosmetic tiles, and when loading the maps, my code sees those Objects and creates appropriate engine-side entities that correspond to them, filling in any missing fields with sensible defaults.
The really interesting work happens in your game code. Instead of just loading some specific map and spawning in all its entities, there’s some extra logic that decides which map(s) to load and which entities to spawn (and where). There are loads of different ways to decide this, and the specific way(s) you’ll do that depend on how you want your game to look and play. But generally the idea is that you build out an abstract representation of the run’s world, often using some sort of constraint solver, which not only determines where the rooms are and how they’re connected, but also where your various game progression “doors” and “keys” are (these might not be literal doors and keys, but may be things like key items, abilities, dialogue checkpoints, etc). Once that abstract representation is in place, you iterate the rooms, and for each one, pick a map that matches its parameters (size, doors, biome, etc).
That last part is a lot easier to do if you have some metadata in a big list describing all the available rooms and their parameters and capabilities. You could read each map and check what Objects and layers are in it, but that’s pretty slow, especially if you’re parsing the map files at runtime. Instead, you’ll probably want to create a data structure with all this metadata in it at build time or earlier. You can scan all the map files at build time, or you can use scripting in Tiled to manage this metadata for you; I advise managing it by hand, as it’s very easy to end up with stale metadata. This pile of metadata can be another file you read in at runtime, or you can generate a header file with it that gets built with the restof your game. The latter is more efficient, but a separate file can be edited by your players to add custom rooms.
…that was a lot of text. I hope at least some of it is relevant. This is a huge topic, in part because these days “roguelike” refers to so many different things and I don’t know which you mean.