How does an end user differentiate between OV and DV certificates?

There is no difference between DV and OF in the browser's identity field. The screenshot below shows this field for Chrome, Firefox and MSIE. For both DV and OV, only the URL (no company name) show in the identity field.

When the site has EV, the company name is displayed along with the URL. Chrome and MSIE use green background to the company name, while Firefox will use green text for the company name.

However, if you look at the certificate itself, you will see the difference.

The two screendumps below are both from the Firefox certificate viewer.

The screendump below is from a site with only Domain Validation (DV). As you can see, there is no information about the organization in the certificate.

The next screendump is from a site with Organization Validation (OV). Here you can see the name of organization that own the domain.

You will also find the name of the organization of a site with Extended Validation (EV). The difference between OV and EV is that the company name is displayed in the browser's identity field if the site has an EV certificate, but not if it has a OV certificate.

Another way to tell DV and OV certificates apart is to inspect the numeric policy identifier (appears under the certificate's "Details"-tab if present). Please note that this identifier is not adopted by all CAs. Values used for the policy identifier are show below:

DV 2.23.140.1.2.1
OV 2.23.140.1.2.2

Why would you think that you can trust companies officially registered in some countries more than you can trust registered domains hosted in any?

EV has obvious advantage with stricter validation, differences in trustworthiness between the other two however are rather moot. Browser vendors supporting EV simply didn't feel the need to agree on a separate visual identification of the other two (OV, DV) verification models, as neither provide a clear advantage one over the other (if any at all).

In short, none of the major browser vendors felt the need or want to differentiate between the two and stand behind it with their name. Good that they didn't, too. If companies can withstand scrutiny EV brings, then no one is stopping them to apply for such certificate. On the other hand, there are clearly also needs for cheaper certificates where additional verification wouldn't fit within their price range. Browser vendors (and user interfaces of some other software vendors) with EV support however don't stand by these cheaper certificates in any other special way than what is already there as per usual, for reasons mentioned before.

As for the other part of your question (visual inspection of certificate data), OV and DV would differ in their description where OV usually holds more data about the company it was issued for, but that's about it. This additional information display can vary across different clients, tho. That image you're attaching is however from Wikipedia, and you didn't mention what browser you were inspecting detailed certificate information in, so I can't say what differences you'd be able to see in an unknown browser.

^{Example of Extended Validation certificate in Mozilla Firefox (above).}

EDIT: DV certificate contains no identifying information in the organization name field. Typically, this value just re-states the domain name or simply says "Persona Not Validated", "(unknown)" et cetera. This is not standard for all CAs tho. Another way would be to inspect policy identifier (if present) where 2.23.140.1.2.1 stands for DV, and 2.23.140.1.2.2 for OV. Again, this is not adopted by all CAs. In short, there is no deterministic way to tell if a certificate was Domain or Organization Validated.

^{Example of Domain Validated certificate in Mozilla Firefox (above). Notice the lack of meaningful data in the organisation information field.}

The extensions and OIDs in question can be read with a run of command-line openssl x509 -noout -text -in <cert.file>.

When doing that regularly, you may want to be exact. Here is a snippet from my own Python 3 certificate helper tool:

known_policies = {
        '2.23.140.1.2.1': 'DV',
        '2.23.140.1.2.2': 'OV',
        '2.23.140.1.1':   'EV'
}
policy_re = re.compile(r'.*(2\.23\.140\.1\.[.0-9]+)', re.DOTALL)
ext = x509.get_extension(idx)
if ext.get_short_name().decode('ascii') != 'certificatePolicies':
    # Other type of extension, not interested in that
    continue

policy_match = policy_re.match(str(ext))
if not policy_match:
    # Doesn't seem to contain valid policy information
    continue

policy_oid = policy_match.group(1)
type = known_policies[policy_oid]

The general idea is to use Python's OpenSSL library to read and load a X.509 certificate. Then iterate its extensions while looking for a certificatePolicies-extension. The expected normal condition is, that there is one of the hard-coded OIDs in extension data.