In Control Panel > Network and Sharing Center, there will be an option to Set up a new connection or network at the bottom half of the page. (Network and Sharing Center will, in the main window, display the networks you are connected to at the top, and then Set up a new connection or network and Troubleshoot problems below.
Click on that, and then when it prompts you to Choose a connection option, select Manually connect to a hidden network, then click Next. It will prompt you for your SSID, security type, and security key. Fill these in as appropriate, and then just click through.
Wi-Fi clients can't tell, before they connect, what wired network a given AP will connect them to.
So if you have two APs publishing the same SSID with the same security type and password (or no security at all), clients will roam to it thinking it's part of the same underlying network. If the two APs actually connect to two different underlying IP subnets, this will break all the higher-level connections or traffic flows (SSH sessions, TCP downloads, video streams, mounted file servers, etc.) that the client had in progress.
In a worst-case scenario that's all too common, if both APs are acting as NAT gateways and using the same private IP subnet, a poorly-written client may not even realize it has switched networks, and may keep sending its Internet traffic to the MAC address of the old AP, not the new AP, until the ARP entry for the router times out. Apple's client devices (OS X and iOS) do something called DNAv4 ("Detecting Network Attachment in IPv4": RFC 4436) to make sure this doesn't happen to them. Whenever a Mac or iOS device's Wi-Fi interface says it has roamed from one AP to another, the network stack and DHCP client double-check that this is really the same network, in order to more quickly re-establish proper connectivity. I called this out in my answer to "How can I get the same SSID for multiple access points?".
By the way, I need to point out that some other Answers to your question are spreading a false myth. Most client implementations WILL NOT look at all "saved" SSIDs for roaming if they're still attached to an AP for one SSID. Most client implementations will stick on the current SSID, and only try to roam within APs of the current SSID, unless the client becomes completely disconnected from the current SSID. The (incorrect) behavior the other Answers describe would completely suck, because let's say you live in the apartment above a Starbucks, and your AP is in the living room, but back in the bedroom, the Starbucks AP is stronger than your own AP. You don't want your client to roam to the Starbucks AP just because it's stronger.
Switching to other "saved" SSIDs only happens if you're completely off the network, such as when your AP is completely out of range (or off or crashed), or on boot, or possibly wake-from-sleep (but I argue that even wake-from-sleep algorithms should make an attempt to get back on the last SSID they were on, especially after a short sleep, in order to provide the best network service continuity).
Edited to add: I should point out that neither the IEEE 802.11 standards nor the Wi-Fi Alliance's specifications and test/certification programs specify the exact roaming and "preferred/saved" network-joining behavior of 802.11/Wi-Fi clients. I've described the behaviors of clients I'm most familiar with (Apple clients), but it's entirely possible that there are poorly-implemented clients out there that do dumb things.
Best Answer
They will need to be reconnected manually.
This isn't a theoretical question or answer, they will disconnect as soon as they miss enough beacon/management frames from the access point. This behavior will be the same across all 802.11 capable devices. It's not that the AP has disappeared when you change the SSID, but it's identifying information has changed from the client view. (BSSID + SSID combination) and their perceived signal strength to the access point will be zero, as there are no longer beacon/management frames being received from the client, this means no RSSI (i.e out of range).
IP Addresses or their DHCP leases have nothing to do with keeping a 802.11 connection alive. Wireless access points work at Layer-2 of the OSI model, or the "physical/link" layer-1 of the TCP model.
Most, (if not all?) Operating system wireless network profiles are based on the SSID. So the client devices will see the new SSID as a whole new network, and thus you will have to reconfigure the clients with the new network credentials.