In 2D or 3D, an entity component system (ECS) should at least have access to the GUI system, if it's not part of the same ECS.
Personally, I wouldn't mix the two. The reusability of code for a GUI only really happens at the top level. Responding to the mouse/keyboard, rendering, and so on. The functions that different buttons take, or the information that certain lists display isn't really something that can be made generic enough to reuse.
For example, I would imagine the components for GUI entities would be something like
gui. Where the GUI component would define the type of action the GUI entity takes. However, that action is going to be pretty unique and context specific. This results in the system that handles GUI components being very large and essentially designed to handle each of the GUI functions (load game, save game, find server, etc). Sounds messy.
I'd prefer to do a standard class file for each GUI "screen". Have all the functionality for that screen in one place (with references to a common functionality class). It's a lot neater and easier to manage.
However, as I said, the ECS should have access to the GUI system. It needs to be able to supply information to the GUI based on entities in its systems. For example, hovering over an allied unit would pop up a GUI window with all the information about that unit. Where hovering over a enemy unity would pop up a GUI window with limited information. You likely don't want to program the GUI to know the difference between the two, you want to ask the entity to display its information.
So, entities will still likely have some kind of GUI component, but they'll be "in game" entities, not GUI entities. This component will use the external GUI system to create their GUI interface.