If there are no inbound or outbound connections, then is using SSL overkill?
My concern is displaying sensitive information in the browser. Even though the information is coming from localhost, it’s still being displayed in the browser which obviously has access to the internet. Assuming the browser, or my machine, is not compromised then I should be fine...right?
SSL only protects the data when it is in transit, your browser/machine can read whatever is on the page regardless of SSL or not. If you are sure your local network is secure then not using SSL is fine and since the server is on localhost it loops back to the machine anyway and doesn't enter the network so all are have to worry about is how secure the machine is.
If you are doing web development for something that is going to be available online, you probably want to use TLS(/SSL) at one point (before putting it online). A proper use of TLS includes things like CSP and other security headers that can only be tested if you are running a HTTPS setup. It would suck if you create a great website which you want to put online one day only to find it broken* after you "enabled" HTTPS.
* By broken I mean certain things like included Javascripts from external sites (either via HTTP, that gets blocked because of mixed content, or because of a CSP rule that you put to protect your site).
Just for development purposes, and for the sake of extra security, is a self-signed certificate sufficient enough to thwart off anyone trying to snoop?
It looks like I can use OpenSSL and the command below to create a generic certificate and key, but it's not password protected. Would this be good enough?
req -new -x509 -days 365 -nodes -out server.crt -keyout server.key
Overkill. If you are at localhost or 127.0.0.1 or ::1 or something that you set your host file to resolve as such that then connection never leaves your computer.
Ever notice in chrome how when you need to enter a password on a non-encrypted site at localhost it doesn't show the 'not secure' in the address bar? This is why, they know that if your at localhost the requests are leaving your computer.
vs
A certificate doesn't change anything about the security. Even though some certificate authorities (CAs) try to make you believe that, there are no differences between the various types of certificates they sell. All the certificates that your browser can work with are the same. Just make sure that the encryption ciphers that are separate from the certificate are decent. A useful tool to evaluate that is https://www.ssllabs.com ("Test your server") or testssl.sh for offline setups.
The reason why for some websites your browser shows the name of the company next to the lock (this is called an "Extended Validation" certificate) is that the certificate is signed by a special root certificate which your browser trusts even more, since the browser vendor made special agreements with the CA that this root certificate will only be used for people who have been through extended validation. This means that the CA hasn't just checked that the person asking for a certificate has control over the domain ("Domain Validation", DV) but that the business that people expect behind the domain is in fact owned by (or has granted permission to) that person. Of course this work doesn't come for free, so naturally these EV certificates are quite pricey.
Since the network requests never leave your computer, it doesn't matter if someone gets a copy of the key since they can't mess with the network traffic from your computer and therefore can't intercept it anyways. If they could, they would already be on your computer and then you have other problems to worry about.
However, if you are getting a "real" certificate for your website later (by a real CA like Let's Encrypt), then you must make sure that your key is protected. It doesn't need a password (if you set one the server can't work with it before you entered the password and therefore restarting the webserver becomes annoying) but make sure that the file permissions are set in a way that only the webserver (Apache, nginx, etc.) can read the key.
Also when you switch to a "real" certificate, make sure you create a new key with it (it's free so why not?).
Finally, if you need some advice on all of these SSL/TLS, HTTPS things, I highly recommend reading up on Scott Helme's posts that he publishes on his website.
When you switch your site online, you can use the fully automatic tool that Let's Encrypt recommends, but you can have more control over it if you are using acme-tiny like he explains here (it's simple):
When you have HTTPS set up, don't forget some important things like security headers that harden your setup further against attacks:
When you are done with that, but you still want to increase your security, you should look at CSP:
You might at one point read about HPKP: HPKP is a header like CSP and HSTS that makes sure that your browser will only accept certain certificate keys for your website and will block anything else. This is amazing for security but not too few people have already messed it up and locked out a lot of their customers and users because of that (even after they have fixed it). So if you go the route to implement HPKP, make sure you have proper backup keys that aren't on the same machine like the webserver. For more information on that, I would recommend you to read his post on that too. 
Sorry for my huge post, but I hope it helps.