After much frustration, I managed to determine that both web.config files (on the client and server, both of which are web apps in this case), the following sections have to be changed:
Client:
<client>
<endpoint
address="http://mysite.com:port/services/someservice.svc"
binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISomeService"
contract="MyServices.ISomeService"
name="BasicHttpBinding_ISomeService" />
</client>
</system.serviceModel>
Server
<system.serviceModel>
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://mysite.com:port/services"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
<behaviors>
<serviceBehaviors>
<behavior name="MyServices.SomeServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="MyServices.SomeServiceBehavior"
name="MyServices.SomeService">
<endpoint address="http://mysite.com:port/services/someservice.svc"
name="endpoint.SomeService"
binding="basicHttpBinding"
bindingConfiguration=""
contract="MyServices.ISomeService"/>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
</system.serviceModel>
The thing to note here is that the host address in all three relevant sections (client endpoint address, server baseAddressPrefixFilter value, and server endpoint address) have to match.
I'm able to switch between servers by modifying these, as long as they match. I would still prefer a way to set this based on which machine the server is running on, but this works for the moment.
WCF Impressions
What's hot: persistent object. The client proxy object (created when you add a service reference) maintains a persistent connection to the service on the server. The service instance referenced by the client proxy maintains its state between calls, which can simplify method signatures and makes the client proxy object, and the service as a whole, much more useful for certain applications. Parameter object types can be shared between the client and server if they're declared in a common library, meaning that you don't have to create two very similar classes or wrapper classes to pass non-primitive data structures back and forth.
What's not: configuration is a royal pain, poorly documented, and far too involved. Getting this to work in a test/dev/staging/production environment configuration where the service neesd to be aware of its location is frustrating. I'm not convinced that making the service aware of its domain url (rather than, say, a relative path to whatever it's running on) has any significant benefit, security concerns aside.
That said, I'm continuing to go down the WCF path as the advantages thus-far outweigh the headaches.