The video driver sits on top of the hardware, DirectX sits on top of the video driver, the engine sits on top of DirectX. Whenever the engine wants to create an object that is to be drawn on screen, it requests the pertinent buffers from DirectX, and implements the pertinent data and interfaces in an engine-specific manner, shielding the end user from the specifics of the DirectX API. In effect, the engine is a middle man. DirectX is still involved, but the end user of the engine doesn't have to muck with it. The guy that wrote the engine does.

As far as implementing an open world game, one of the key obstacles you have to overcome in your design is streaming. This is how they implement large worlds without loading screens. At any given time, the only world geometry that is currently resident in memory is what is required to draw the view, plus some buffer area around it to account for movement. As the point of view translates, additional world geometry is streamed in and stuff that moves beyond the padding zone is pushed out. Given the relatively slow rate of movement compared to the size of the visible area, this means that a relatively small amount of data is loaded each update. This is also why large open-world games frequently do have loading screens when you teleport elsewhere, as you can no longer incrementally stream in the data you need. You have to load the new visible zone all at once.

It's a fairly complicated problem that requires a strong understanding of multi-threaded programming, task scheduling, and representation of the world in order to simplify the process and make it as tight and streamlined as possible. Each company is probably going to have their own framework for it, and yes, that framework and the details of it is probably going to be covered by an NDA.

I don't understand exactly what you mean by "how do they draw the game world at realtime rather than crating a model etc". They... uh... draw the game world by populating buffers with data and issuing draw calls to the engine.