Key Check Value standard practice for asymmetric cryptography? I'm looking for a standard, or sound industry practice, for the equivalent of a Key Check Value, applied to the private key of a public key algorithm, like ECDSA.

For DES or 3DES keys, practice (as worded e.g. in EMV Card Personalization Specification) is:


  6.1.5 Key Check Value
  Purpose: The data is used to prove that a card/processor has access to a
  specific DES key value.
  Format: Binary, 3 bytes
  Contents: The three leftmost bytes of the result of encrypting eight bytes of zeros by the DES key concerned.


Notice that the above definition is slightly wrong: the KCV as defined does not prove anything beyond knowledge of the KCV. The actual purpose (and the one I'm interested about) is to guard against a wrong value of the key, either accidental, or deliberate from one participant in a scheme where the key is rebuilt from shared secrets (for simplicity, assume that's by XOR of the components, and that at least one participant does not cheat).
PKCS10 looks like relevant industry practice for private keys.

See "Note 2" at page 4,
Certification Request Syntax Specification - RFC 2986:
The signature on the certification request prevents an entity from requesting a certificate with another party's public key.

That is, soneone requesting a certificate on a public key demonstrates his knowledge of corresponding private key by producing a signature verifiable with the public key from PKCS10 request.

Another technique could be found at Join protocol,
Direct Anonymous Attestation
for Trusted Platform Module chip.
It could be considered a proof that TPM "has access" to "keys" $f_0$ and $f_1$.