"Spawning" things mid-game is pretty much non-existent. The only way to do it (I'm pretty sure) is with the launcher nodon, and that is limited to only spawning basic objects of the three basic shapes - cuboid, sphere, cylinder. Everything else you make needs to exist somewhere in the game world at start time.
With my current teleporter efforts, I figured that to e.g. remake Mabe village from Link's Awakening I'd need to have buildings the player can enter/exit. This is trivial to do with a teleporter entrance and exit on each door, but you'd need to use two exits per building (one for entering, one for exiting) and the game has a limit of eight exits - so that's four buildings total, which is not enough!
So instead I thought - what if there is a teleport entrance attached to the player themselves, so it follows the player around, but instead of triggering on touch as default (it'd teleport you constantly!) I controlled when to trigger it. Then each building entrance/exit would have a touch sensor that triggers on the player touching it, and this would trigger a signal from two constants sending the x and z coordinates of the desired teleport destination to a mechanism for moving the teleport exit and triggering the teleport attached to the player.
In principal this is fine and pretty simple, but the mechanism for moving the teleport exit into place is where I have been really struggling. I'm using a free slider placed at the origin (0,0), so in theory it should be as simple as passing the destination coordinates to this, teleporting the player, then resetting the coordinates. In practice this only works over very short distances because (at my best guess) the underlying game engine really doesn't like large instantaneous velocity changes. At anything other than very short distance, and especially when moving on both axes, the free slider will basically just break - I'd see the telport exit bugging out and jumping around at insane speeds, even gaining height on the y axis when it shouldn't. It was completely unreliable a setup.
Since then I've just been progressively trying to error correct and make robust that mechanism for moving the teleport exit. I currently have something that works on a single axis which I need to extend to both - but frustratingly I appear to need to move only on one axis at a time to keep things behaving.
A fun example of the kind of unexpected error correction I am doing: I am checking the player has been teleported by comparing their x and z location against the x and z location of the destination coordinates and of the x and z location of the teleport exit. These should all align, and in fact they do appear to align to two decimal places (which is the most precision you can display). But if I try this comparison just with an "=" nodon, it often returns false! My working theory is that there is some precision loss in the movement of the teleport exit and it is actually out by <0.01m. I replaced the "=" comparison with a setup that finds the difference between the coordinates being compared, takes the absolute value and checks it is < 0.01. This works! Basically I had to make my own equals comparison that allows for a small margin of error.
Anyway, after all this I am now determined to get it working reliably, but I'm convinced it won't actually be that useful a setup, because it'll end up taking up 20% of the nodon limit itself.
Which is to say, making portal seems unlikely