How is it possible for a VPN connection to be created through the ISP? I will be theoretical here. Let's say you want to create a VPN connection with some VPN provider. You have to agree on some key to encrypt the data. how can you get the key without your ISP knowing it? Even if you are the one who creates the key, the ISP still sees it as it's being sent to the VPN provider.

An analogy would be, say...
Alice(you, or the client), John(ISP), and Bob(VPN provider) are sitting in a room.
Alice is trying to convey a message to Bob without John understanding it.
So Alice tells Bob that they will speak French(instead of English). Now john knows their language. no accomplishment. Even if Alice talked about a complex method of encrypting the message, John will know it, since he is in the room.

Unless Alice and Bob had agreed on a method before they were in the room, they won't be able to communicate privately.

An other way would be for Alice and Bob to already have some keyword X which only they know, which counts as 'a method before they were in the room', but I think that's unlikely in a VPN.

End of analogy...

So how is it possible for you and VPN provider to communicatea key without ISP knowing it?
So how is it possible for you and VPN provider to communicate a key
  without ISP knowing [that you are communicating]?


You can't. The ISP will always see that there is some traffic going on. Whether the ISP will be able to see with whom you are (actually) talking depends on whether you use things like TOR and on the details of the target network, but in general the packet metadata will tell the ISP where to send the packet and thus with whom you are talking.


  So how is it possible for you and VPN provider to communicate a key
  without ISP knowing [the key used to encrypt the data]?


This is due to the "magic" of asymmetric cryptography. In short, this allows you to reduce the requirement from a trusted, secret channel (to transport a symmetric key) down to an authentic channel, ie a channel where nobody gets to alter, drop or insert malicious messages***. And as you may have guessed, in current TLS versions (1.2 and earlier**), if you use a so-called "ciphersuite" without DH, DHE, ECDHE or ECDH in the name, you are essentially encrypting a secret with the server's public key, sending it and then you both go from there and derive a key* for the session.


*: To get some neat extra security properties.
**: TLS 1.3 has explicitely removed this type of ciphersuite because of something called forward secrecy.
***: So-called certificates are then used to reduce this requirement even further from "always need authentic channel" to "sometimes need authentic channel + need to trust a third party"