I would not say that you don't have a lot of VRAM.
Regardless of whether VideoMemorySizeMb is manually or automatically set, it refers to the same thing - memory used for caching textures and object geometry (the 3D information about things being rendered.)
If VideoMemorySizeMb is set larger than your physical VRAM, then - if needed - system RAM will also be used to cache data.
Whether ENB actually needs to use that much memory for cached data depends on what mods you're using, especially including higher-resolution texture replacers, and where you are located in the game (because some areas require the loading of a lot more textures than other areas.)
Although you are unlikely to use it all, manually setting your VideoMemorySizeMb to 16GB when you only have 16GB of system RAM is not a good idea. Skyrim itself has already claimed 4GB, and if ENB tries to use over 12GB of system RAM, well, there's nothing left to do but start using virtual memory (the Windows "swap" file) or just crash - and I haven't even accounted for the RAM that the Windows system itself needs to run.
Keep in mind that the Direct X part of the NVidia drivers is probably allotting RAM itself, up to the same as the amount of your VRAM, so in your case, very likely Video memory would show up as 4095MB if you run DXDiag. So, a safe place to start with the VideoMemorySizeMb in enblocal.ini is setting it manually to be the same as your VRAM - so 2048. As a starting point.
Then there's the ReservedMemorySizeMB setting in enblocal.ini, which you didn't mention, but which can affect things, as well as EnableCompression.
If you do decide to reduce VideoMemorySizeMb and find that the MS VisC++ RL errors show up again, I'd suggest toggling ExpandSystemMemoryX64 from true to false, because it doesn't necessarily "expand" system memory, but rather it changes what part of the memory allotted to Skyrim (TESV.exe) is used for cached data. For some reason, this can cause Skyrim to crash for some people with it enabled and for others with it disabled. So it's worth a try changing it for troubleshooting purposes.
Finally, to answer your question about the order of the settings in enblocal.ini - there's no problem with it not matching what you see from STEP, but it certainly makes it easier to check if your order matches. I think the STEP order of the settings is the same as is found in the original ENB binary download copy of enblocal.ini, if I'm not mistaken.