Would globally aliasing the fork bomb prevent its execution?

The two, no, three, ... Amongst the main obstacles to that are:

1. It's not a valid name for an alias. Bash's online manual:

   The characters ... and any of the shell metacharacters or quoting characters listed above may not appear in an alias name.

   (, ), &, | and whitespace are out in Bash 4.4.

2. That particular string is not the only way to write a fork bomb in the shell, just famous because it looks obscure. For example, there's no need to call the function : instead of something actually composed of letters.

3. If you could set the alias, the user could unset the alias, circumvent it by escaping the alias name on the command line, or disable aliases altogether, possibly by running the function in a script (Bash doesn't expand aliases in noninteractive shells).

4. Even if the shell is restricted enough to stop all versions of a fork bomb, a general purpose system will have other programmable utilities that can recurse and fork off subprocesses. Got Perl or a C compiler? Easy enough. Even awk could probably do it. Even if you don't have those installed, you'll also need to stop the user from bringing in compiled binaries from outside the system, or running /bin/sh which probably needs to be a fully operational shell for the rest of the system to function.

Just use ulimit -u (i.e. RLIMIT_NPROC) or equivalent to restrict the number of processes a user can start. On most Linux systems there's pam_limits that can set the process count limit before any commands chosen by the user are started.

Something like this in /etc/security/limits.conf would put a hard limit of 50 processes to all users:

*        hard    nproc           50

_{(Stephen Kitt already mentioned point 1, Jeff Schaller mentioned 2 and 3.)}

No. There are just too many ways to write a fork-bomb.

The evil fork-bomb writer will just try again with a different function name. Or other alterations until his fork-bomb succeeds.

The inadvertent fork-bomb writer won't produce the canonical fork-bomb in the first place.

It's actually rather easy to become an inadvertent fork-bomb writer yourself. For instance, you could just use recursive make with an external, unchecked cd, combining it with the -j option and non-existing subdirectories -- a real example I've stumbled upon once.

You cannot safeguard against all possibilities, and most certainly not against a determined attacker. All you will achieve is to increase the complexity of your system.

You can’t alias a fork bomb, because it’s not a valid alias name:

$ alias ':(){ :|:& };:'='echo fork bomb averted'
bash: alias: `:(){ :|:& };:': invalid alias name

The characters ‘/’, ‘$’, ‘`’, ‘=’ and any of the shell metacharacters or quoting characters listed above may not appear in an alias name.

Some shells don’t check alias names when they’re declared, but when interpreting commands, and skip the invalid name then. A fork bomb will always include &, which can’t be included in a valid alias name, so protecting yourself in this way isn’t possible.