In short, no, but there might be subtle cases depending on how you want to deploy the system.
HTTPS is HTTP over SSL/TLS, and you can use SSL/TLS without certificate or with certificates of other types than X.509.
- Anonymous cipher suites: they can provide encryption, but without authentication. Rather useless as far as security is concerned... To quote RFC 4346: "anonymous Diffie-Hellman is strongly discouraged because it cannot prevent man-in-the-middle attacks."
- Pre-shared keys: it has its own mechanism to verify the remote identity, but the shared nature of the keys brings its own set of problems (in particular limited deployment).
- Kerberos cipher suites: the client can verify the identity of the server against the Kerberos principal name.
Strictly speaking, the HTTP over TLS specification says the following:
In general, HTTP/TLS requests are generated by dereferencing a URI.
As a consequence, the hostname for the server is known to the client.
If the hostname is available, the client MUST check it against the
server's identity as presented in the server's Certificate message,
in order to prevent man-in-the-middle attacks.
If the client has external information as to the expected identity
of the server, the hostname check MAY be omitted. (For instance, a
client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man in
the middle attacks. In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.
In short, it's clearly intended for usage with an X.509 certificate (it clearly references RFC 2459, later superseded by RFC 3280 and 5280: PKIs with X.509 certificates).
There can be an edge case when you're using Kerberos cipher suites. It may make sense to treat the server's Kerberos service ticket could be assume to have the same purpose as the X.509 certificate in usual HTTPS, for the verification of the remote party's identity. It doesn't quite fit within the rules of RFC 2818 (although it might fall under "If the client has external information as to the expected identity of the server, the hostname check MAY be omitted."), but it wouldn't be completely absurd.
This being said, I don't think usual browsers support TLS Kerberos cipher suites in general (a number can support Kerberos via SPNEGO authentication, but that's unrelated). In addition, this would also only work in an environment where using Kerberos is suitable.
"[Giving] the consumer peace of mind that they are connecting to the correct website" is actually one of the key requirements for securing the communication between them and your server. Do use a certificate they can verify, with the appropriate naming conventions (RFC 2818 or more recently RFC 6125).
