Yes, you can generate during runtime.
If you call the Generate function, then the previous rooms unload, and a new dungeon generate and load new rooms.
There is no map travel during the process, the player remains in the master map, only the dungeon's rooms are loaded/unloaded.

You are only limited by the performance of the machine your game runs on.
Mostly, the performance of the dungeon depends on the complexity of your rooms/meshes, and the hardware of your computer. The more details and diversity of actors there are, the more resources will be consumed on the computer.
To be able to generate a very large map, you will need to optimize the meshes/textures for the RAM and GPU, the collisions and number of dynamic actors (enemies, etc.) for CPU, etc.
The simple occlusion culling system I provide in the plugin is one (rudimentary) way to optimize the GPU side (less drawing). It is far from perfect but a good start.
You will need to do the other optimizations yourself.

There is no save/load system implemented in the plugin. You will need to do it yourself.
I made this plugin for a rogue-like game, so I didn't made a save/load system of the dungeon.
A starting point will be to save the dungeon seed, and any other dynamic actors of your game.
You would set an ID for each actors in the room's levels that need to be saved (using the dungeon's seed). Then when you load a game you can retrieve the actors from their IDs in the generated dungeon, and apply the saved data to them.

You can have the number of room you want, there is not really a limit in the plugin.

Yes, you can design everything you want in the room. It is the purpose of the plugin: providing a generic way to generate a dungeon, without any compromise on the DA nor the game design.
If you want to add dynamic actors (like enemies, chests, etc.) I would suggest you to create spawners that you place in your room's levels, and spawn those actors after the dungeon generation.
For game save, you should provide a unique id (seed) for each spawner based on the dungeon's seed, so the random spawning of enemies or chest loot will be deterministic from the dungeon's seed.
For multiplayer, you should do the spawning only on the server side. The spawn command will be sent to the clients and the actors spawned will then be replicated correctly.

The occlusion culling is client side. It will show only the room where the local player is and any adjacent rooms.
You can read further details about the occlusion culling system of this plugin from the wiki page.
You can also disable the occlusion culling from the plugin's settings and do it yourself in another way.

Yes, there is a seed for the dungeon generation.
I made a parameter in the DungeonGenerator actor to have different types of seed:

• You can have a fixed seed you can set in the actor which will be always used (useful for testing and debugging purpose, or to set manually the seed from the game).
• You can have an incrementing seed, using the fixed seed for the first generation, then adding a value to it at each generation (useful for demonstration purpose).
• You can have a random seed generated for each generation (for released game mostly, or to test quickly a lot of dungeon generations).

Yes, you can define the flow you want for your dungeon. It is the purpose of the plugin.
There is the function ChooseNextRoomData where you define what I call your "rules" of the dungeon.
You can, for example, check a minimum number of room before spawning a secret room, and then don't spawn it if you already have one in the dungeon.

Of course, you can. To do that sort of thing, you should create a child blueprint of RoomData class to add new parameters like a DifficultyLevel, which you can set value for each rooms in your RoomData assets.
Then for example, in your ChooseNextRoomData function you can choose a room depending on its difficulty level compared to the difficulty level of the previous room.