Sort of - @jsha has more of the history/context here so I'll tag him in advance to correct anything I get wrong 
My understanding is we can't omit the CN all-together as it causes pretty considerable compatibility issues with a variety of client software. Our alternative was going to be to place something other than a domain identifier in the field, but a strict reading of the baseline requirements forbids this. Quoting @jsha's reply in the thread @tdelmas linked:
To avoid creating compatibility problems, Let’s Encrypt never issues with an empty Subject. Another approach, which should be broadly compatible, would be to insert a “junk” field other than CommonName in the Subject. We originally thought to do this by copying the serial number field into the subject, but it’s been suggested that the Baseline Requirements would term this “Subject Identity Information,”
Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include a domain name listed in the subjectAltName extension or the Subject commonName field.
Since Let’s Encrypt uses the CA/Browser Forum domain-validated OID (2.23.140.1.2.1) in its certificates, the certificates are not supposed to have Subject Identity Information
So to connect back to @noloader's question:
It is not possible at this time.
The web server operated for years with a certificate that omits the CN. There have never been any user complaints or operational problems. So we know it is fine in practice.
I don't think you can necessarily draw this conclusion from one data point. Maybe you have had compatibility issues that weren't reported to anyone. Maybe this server's traffic is biased to specific regions/client software that would preclude incident. If Let's Encrypt's operational experience has been any indicator the web PKI has an extremely long tail and I'd be nervous about extrapolating too much on compatibility questions.