It turns out that the security thing was a red herring.
Lesson #1: The Nodebb installation pdf says to insert "auth=true" in the file /etc/mongod.conf. This is not only incorrect syntax for the modern YAML world, but it is unnecessary. Mongo defaults to "security: authorization: enabled" (which is, I believe the correct element).
Lesson #2: This is what was actually broken. The configuration file that installs with Mongo (apt-get...) specifies a file path for the database. Incredibly, that file path is not correct. The default location for mongo's data is /data/db. The file, /etc/mongod.conf, has something else. My problem was that Mongo was looking at the wrong database file which didn't have the correct user. Hence, authentication error.
It turns out that mongo does not use a config file unless you specify one. There is no default config file. In particular, /etc/mongod.conf is not used when you start mongod from the command line.
Since the nodebb installation PDF specifies that file for "auth=true", I was very confused. My confusion was made much worse by the boilerplate mongo Upstart script I got (and am pained to say that I cannot remember where it is) referenced /etc/mongod.conf.
It is entirely unclear to me whether Upstart operation actually requires a config file or if it would start it correctly without one. I prefer a config file because it documents where stuff is when I need to debug later. The config file now includes "storage: dbPath: /data/db" instead of whatever bad old stuff it had.
Lesson #3: Once I figured this out, it still did not work. The log said it was "Unable to create/open lock file: /data/db/mongod.lock".
The problem results from the fact I installed Mongo as root and ran it for the first time as root. That means that its files were owned by root. This was not a problem when I ran it from the command line because I did that as root, too.
Eventually I figured out that the Upstart script, appropriately, runs as user 'mongodb'. This user was not able to work with the files owned by root.
Obviously, the remedy was to change the ownership of /data/db. But, I already had a substantial amount of data in those files so I had to figure out how to back it up in case I killed something. Mongodump is the answer and worked quickly and easily.
I did "chown -R mongoldb /data" and then rebooted the server. It worked.
Bottom Line: The Nodebb installation docs need some fixing. The Ubuntu Mongo install needs some fixing. I need to trust received information somewhat less.
Thanks, julian and qgp9, for your help.
[updated to add a line of explanation about the consequences of the goofy database path error.]