This kind of procedural creation occurs during runtime as part of the game execution, so when the game stops running it returns to its constructed state. This does not permanently change your level. The ULevel itself (and the .umap file) aren’t ever modified, it’s just executing code to spawn actors within the running level (as you would spawn enemies, projectiles, etc. during gameplay - it would be weird if gameplay permanently added objects to the level by default).
Alternatively, you could create an actor that exists within your level that reads the spawning data and constructs the desired objects, or you could build the spawning method(s) directly into your level; but again, these created objects will only exist during runtime.
You could spawn the objects during level construction rather than after BeginPlay, they would then show up in the editor; but they still don’t exist as part of your level, they’re being spawned within the level as part of the execution of your game.
If you need to store the data in the .umap itself you’ll need to do some work on the editor itself, creating a utility (probably a plugin) that actually modifies the ULevel object, perhaps even creating a custom ULevel class.
You might be able to save a .umap file during runtime, but you’ll still have to see how the editor does that and be sure you generate the paths and data structure the same way UE4 does, otherwise you’ll have untold problems. It’s probably easier to write it as a plugin than as a runtime gameplay element.
Regardless, you’ll need the content assets to have the same file structure within the new game project as in the existing one in order for the levels to load properly.
See:
https://docs.unrealengine.com/latest/INT/Videos/PLZlv_N0_O1ga0aV9jVqJgog0VWz1cLL5f/zg_VstBxDi8/