No, because every language has one specific set of abstractions and interfaces chosen by the language's developers. This is the same for textual and visual programming languages alike.

What might well be very hard is making a language where all abstractions and interfaces map to useful graphical representations; I imagine it's much, much easier to represent a JSON object graphically than it is to represent a piece of C code this way.

For instance, how would jumps look? Lines going from far-removed boxes, producing code that literally looks like spaghetti? Moreso, do you even want to graphically represent things like pointer arithmetic, will this be easier to work with? How do you represent variables, globals?

Maybe you would only represent course features such as data flow graphically, and hide finer grained details and code in "blocks" with labels and defined in- and outputs. You would still mostly write your code, but the graphical view might help you mentally model your program.

Actually, the graphical aspect of a visual programming language is often an "un-abstraction." Text is pure abstraction with little static context beyond names. VPLs often attempt to provide more context by (a) mixing in execution context (like in Quartz Composer) and (b) through direct mappings to the domain (e.g. a VPL for layout that has you manipulating layouts directly). Much of the usability benefits, as well as scaling problems, that arise in VPLs is due to trying to them trying to be less abstract.

It doesn't have to be just another abstraction layer. In Full Metal Jacket, there's no underlying human-readable text-based language. The abstract machine it's designed to run on is highly-concurrent (MIMD) dataflow, which is very different from the von-Neumann architecture. You can represent concurrency visually better and more clearly than textually, though a few dataflow-based textual languages exist such as SISAL.

At present, FMJ is interpreted and runs on a virtual dataflow machine. This was a necessary step to ensure the computation model was implemented accurately. Compilation to run on a single processor would actually be simplified, however: there's no parsing or dataflow analysis required. Looking into the future, the question that should really be asked is whether languages designed to run on a single processor, or to execute the same instructions in parallel (SIMD), can be easily adapted to run on MIMD architectures. Do you really want to be using MPI?

Most languages compile the source to an AST, so I would say the AST is one level of abstraction below source code. Then, text and graphical languages could be equally powerful if each can represent any AST the other can.

I have done some programming in these and they are definitely more suited to the applications that their creators had in mind.

I wouldn't want to do general purpose programming in them -- at least as they exist currently.