As an end user, not easily, unless an attacker brags about it or a site owner discovers it, you can't tell what's actually been lost.
For the technically adept, anyone (end user or site operator) running Snort or another IDS/IPS can look for indicators of realtime compromise in Snort rule form, as the attack can go both ways (your client can be attacked, too, if it's vulnerable). This doesn't tell you if someone else has attacked the website in the past, but it might tell you if someone's attacking you right now.
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - SSLv3 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 00|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000000; rev:4;)
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - TLSv1 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 01|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000001; rev:4;)
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - TLSv1.1 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 02|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000002; rev:4;)
alert tcp any [!80,!445] -> any [!80,!445] (msg:"FOX-SRT - Suspicious - TLSv1.2 Large Heartbeat Response"; flow:established,to_client; content:"|18 03 03|"; depth: 3; byte_test:2, >, 200, 3, big; byte_test:2, <, 16385, 3, big; threshold:type limit, track by_src, count 1, seconds 600; reference:cve,2014-0160; classtype:bad-unknown; sid: 1000003; rev:4;)
Site owners might detect compromises on a site that was recording a full packet sniffer trace, and was actually able to inspect the response sizes of heartbeat requests; other than that, it's very difficult to detect after the fact.
Other possible ways for site owners to detect it would be traffic analysis - having sent too many outbound responses of just over 64KB would be a warning sign, for instance.
Right now, though, there are several Heartbleed vulnerability detectors/checkers that I'll list for the community.
Qualys SSL Labs is more or less the canonical free SSL test site; they added an experimental Heartbleed test hours ago (and set the security grade to F for every site that's found to be vulnerable.
titanous on github appears to still be under active development, and titanous also released Go programming code for Heartbleed detection, had better messages than Filippo as of this morning, and was last updated 32 minutes ago. It appears to be under the Go license, though I didn't do a full comparison; similar to a BSD 3 clause license.
Filippo.io was one of the first Web sites, and they released their code on github with an MIT license (Go programming language), and was last updated 4 hours ago.
musalbas on github released the Python program "ssltest.py" about 10 hours ago that can do mass/bulk tests in only 178 lines (including a few comments), no license listed. Musalbas also released lists of the results of scanning the top 100, 1000, 10000, and 1 million Internet sites as of about 7 hours ago. This is a variant of Stafford's code.
possible.lv is another web site that does Heartbleed vulnerability scans.
Codenomicon Defensics appears to do detect Heartbleed as well.
@Lekensteyn released the pacemaker python client checker, modified a few hours ago, as well as the original Stafford version of ssltest.py. No specific license is listed.
Metasploit is also gaining Heartbleed tests very rapidly, including both the server check linked here and a client check from @HDMoore and @Lekensteyn.
Per @DrJimBob, the LastPass Heartbleed checker is a very nice setup for a Web checker; in particular, it also checks the SSL cert! Output looks like this:
Site: security.stackexchange.com
Server software: Not reported
Vulnerable: Possibly (might use OpenSSL)
SSL Certificate: Possibly Unsafe (created 9 months ago at Jul 2 00:00:00 2013 GMT)
Assessment: Wait for the site to update before changing your password