Of course you can use the primitives of TUI, especially with mouse support, to reproduce a large amount (if not all) of the standard GUI interaction paradigms.
But it's bizarre, and missing the point from a UX perspective.
As an extreme example, we can imagine a program that displays the borders of a 40x15 "window" in the middle of a console, with box-drawing characters, putting a "close box" in an upper corner, with text like "File Edit Help" in the top left. We can imagine it responding to a click on the "File" text by popping out a "menu"; we can imagine a drag starting from the "title bar" causing the window position to be update (and the entire terminal window redrawn).
A lot of those kinds of functions, ironically enough, might make sense for a TUI editor implemented as a TUI (except the "windows" might just be understood as panels where the ultimate program displays parts of its output). But as an emulation of GUI windows, it'd be a strange, impractical novelty.
Even in your example, it's pretty clear cut. If the window is built with text and served in a terminal emulator, it's a TUI. If you build it with a graphical framework that now needs X11 or whatever, it's a GUI.
This is just needlessly pedantic.
The issue is not the text. It's the WIMP interface.