In bash, how do I execute the contents of a variable, VERBATIM, as though they were a command line?

I need to construct a complex command that includes quoted arguments. As it happens, they are arguments to grep, so I'll use that as my example and deeply simplify the command to just enough to demonstrate the error.

Let's start with a working example:

> COMMAND='/usr/bin/grep _'
> echo $COMMAND
/usr/bin/grep _
> $COMMAND
foo            <- I type this, and grep filters it out. 
foo_           <- I type this, and.....
foo_           <- ... it matches, so grep emits it.

"foo" is not echoed back because it lacks an underscore, "foo_" has one, so it's returned. Let's get to a demonstration of the problem:

> COMMAND='/usr/bin/grep "_ _"'
> echo -E $COMMAND
/usr/bin/grep "_ _"
> /usr/bin/grep "_ _"  <- The exact same command line
foo                <- fails to match
foo_ _             <- matches, so it gets echoed back
foo_ _
> $COMMAND             <- But that command doesn't work from a variable
grep: _": No such file or directory

In other words, when this command is invoked through a variable name, bash is taking the space between underscores as an argument delimiter - despite the quotes.

Normally, I'd fix this with backslashes:

> COMMAND='/usr/bin/grep "_\ _"'
> $COMMAND
grep: trailing backslash (\)

Okay, maybe I need another layer of escaping the backslash:

> COMMAND='/usr/bin/grep "_\\ _"'
12:32 (master) /Users/ronbarry> $COMMAND
grep: _": No such file or directory

And now we're back to square one - the command line is still being broken up at the space. I can, of course, verify all of this with some debugging, which establishes that the backslashes are surviving, unescaped, and grep is being called with multiple arguments:

> set -x
> $COMMAND
+ /usr/bin/grep '"_\\' '_"'  <- grep is being called with two args

I have a solution to the problem that takes advantage of arrays, but packing commands this way (in my full implementation, which I'll spare you) is unfamiliar to most people who'd read my code. To oversimplify the creation of an array-based command:

> declare -a COMMAND=('/usr/bin/grep' '-i' 'a b')
12:44 (master) /Users/ronbarry> ${COMMAND[*]}
foo           <- Same old, same old
fooa B        <- ...
fooa B        <- Matches because of case-insensitive (-i) grep.

Finally we get to the question. Why does bash break up quoted arguments in strings when interpreting them as commands and why doesn't there seem to be a string-y way to get it to work? If I have a command packed in a string variable, it violates the Principle of Least Surprise to have that string interpreted differently than the string itself would be. If someone can point me at some docs that cover all of this, and will set me at peace with why I have to resort to the infinitely uglier mechanism of building up arrays with all of my commands, I'd very much appreciate it.