...can I just have an event which is "every millesecond" then have tons of events under that event as sub-events?
No, you can't!
I can't stress this statement enough. 'every x millisecond' is not a reliable way of programming time based! Its timeslice is dependent on the framerate and that is exactly what you try to avoid when using a delta time.
If your game runs at 60 fps, the shortest timeslice you get for 'every' is 1/60s, ~17ms. You could try to set the condition to 17ms, but if for whatever reason the game runs on another computer with 30 fps the shortest timeslice is 1/30 or ~34 ms. In result, the game will be half as fast as on the first computer, because the 'every'-event is still triggered on every tick...
Btw, the example above also shows, that you can't even set the actual values but an approximation (e.g. 17 instead of 16.666666666666...)
This is actually an interesting problem because the Every event can only trigger at most once per tick (like Always). So if you're running at 10fps, the Every event will only trigger at most every 100ms. This is kind of awkward because it can make things framerate dependent again, even in well-designed, framerate-independent games.
'Every x milliseconds' also triggers in the next possible tick, not at the exact time. For example, with 60 fps, the 20th tick is reached at 333.33333333...ms, the 19th at 316.6666666...ms. If you'd now have it run 'every 320 milliseconds' it will occur in the 20th tick, not in between tick 19 and 20. This isn't that bad when just, let's say, switching a light on and off, but it is crucial when constantly moving a sprite or fading a color, etc. It will get slowly out of time.
Here is a cap. Run it and watch for a while (half a minute or more). The two sprites are both set to repeatedly move 400 pixels per second. The one above uses timedelta, the one below uses 'every...' I think, seeing this is better than a thousand words.