This is technically a programming question, not a security question, but it gets deep enough into the weeds of Windows CNG that I'll answer here rather than voting to move.
The function you're looking for is SslOpenProvider, which uses the same NCRYPT_PROV_HANDLE type that NCryptOpenStorageProvider does, but works with Crypto API Next Generation "SSL providers" rather than "storage providers". Note that you can install your own SSL provider (just as you can install your own storage provider), but the default provider returned by SslOpenProvider is Microsoft's own SChannel, implementing the cipher suites that Microsoft provides. To get the list of installed SSL providers, use SslEnumProtocolProviders, and iterate over the returned array's names and comments.
You can indeed call these functions yourself, if you want to implement a TLS client or server instead of using the one built into Windows (SChannel), or if you want an existing client or server to use a non-default provider. Because you're implementing your own client/server, you would be the one making decisions about how to implement things like certificate validation, cipher suite selection, handshake logic, and so on (you'd essentially be replacing SChannel). Of course, you might reasonably use a key storage provider and/or the built-in Windows certificate APIs such as CertCreateCertificateContext to work with certificates and their private keys. This could also be used for implementing things that aren't exactly SSL/TLS, if you wanted (either new / experimental protocols, or other secure communication protocols).
However, you also might write your own implementation(s) of these functions (or wrappers around implementations in e.g. an external TLS accelerator device), package it into your own CNG SSL provider, and expect the existing Windows libraries to call your provider (either because the client/server application requested it, or because you made your provider the default, or because you're using a cipher suite that only your provider offers). Note that, at present, there's a lot of overlap between CNG SSL providers and CNG algorithm providers, such that e.g. SslVerifySignature is apparently not currently used by Microsoft's TLS server implementation, and instead it calls NCryptVerifySignature (the CNG generic function for verifying asymmetric digital signatures). Providers do have to implement the full API, but can simply wrap functionality exposed by other providers for anything they don't want to provide their own implementation of.
The CryptoAPI Next Generation (CNG) architecture in Windows uses pluggable "providers" to implement nearly all functionality, rather than hard-coding implementations. These providers are divided into various types, such as algorithm providers (implementing primitives such as ciphers and hashes, and constructions such as modes of operation or HMAC), key storage providers (used for hardware- or software-based storage and handling of cryptographic keys, including the private keys for certificates), and SSL providers (implementing full cipher suites as used in various SSL/TLS protocol versions). Providers don't implement things like certificate handling or movement through the TLS state machine. Instead, they handle slightly lower-level behavior such as key exchange and derivation, and encrypting or decrypting packets. These behaviors may in turn be delegated to lower-level providers that implement the actual primitives and constructions.
Thus, Windows certainly does call (some of) these functions, any time SChannel is used to establish a TLS connection from the client or the server side. Having Windows' TLS implementation sort of "talking to itself" across the consumer/provider line of CNG may seem strange, but it makes a lot of sense when you consider that e.g. you might want to offload certain operations to dedicated accelerator hardware, while keeping most of the actual TLS logic in the existing library.
