What about creating an as-root D-Bus service, then making the default command line program one which queries the service.  The response to D-Bus queries could vary based on if the requester is root or not.  Or the client could have to request the info one field at a time, and the server could refuse to give info on certain sensitive fields for non-root requesters.

Well, actually /sys/devices/virtual/dmi/id was created exactly for this purpose: let non-root users access the most popular DMI strings.

Dmidecode currently reads the DMI data from either /dev/mem or /sys/firmware/dmi/tables. Both are restricted to root, by the kernel. There is nothing dmidecode itself can do about that.

Adding support to let dmidecode read from /sys/devices/virtual/dmi/id would make no technical sense. For one thing, dmidecode expected a raw (undecoded) DMI table as its input. Having to parse arbitrary text files would require a significant amount of totally new code. For another, there isn't enough information there to rebuild a DMI table anyway. The information would be so partial that I doubt anyone would be interested. If you want to collect as much information as possible, this is a shell one-liner:

(cd /sys/devices/virtual/dmi/id && grep . * 2> /dev/null)

If you really want dmidecode to be usable as non-root, the only sane approach I can think of would be to make files under /sys/firmware/dmi/tables world-readable and let the kernel obfuscate the sensitive information for non-root. However it may be tricky to define "sensitive" in this context. At the moment, UUIDs and serial numbers are considered sensitive. But if we expose the whole table, then things like OEM-specific entries or fields might as well contain sensitive information.