I'm working on an online multiplayer game. I already developed the login servers and database for any persistent storage; both are written in Python and will be hosted with Google's App Engine. (For now.)
I'm relatively comfortable with two languages - Java and Python. I'd like to write the actual gameplay server in one of those languages, and I'd like for the latency of the client to gameplay-server connection to be as low as possible, so I assume that the majority of gameplay data (e.g. fine player movements) will need to be sent via UDP connections. I'm unfamiliar with UDP connections so I really don't know where to begin designing the server.
How should the server be threaded? One thread per client connection that retains session info, and then a separate thread(s) to control autonomous world changes (NPCs moving, etc.)?
How should relatively large packets be transmitted? (e.g. ~25 nearby players and all of their gameplay data, usernames, etc.) TCP or UDP?
Lastly - is it safe for the gameplay server to interface with the login server via HTTP requests, how do I verify (from the login server's perspective) the gameplay server's identity - simple password, encryption?
Didn't want to ask this kind of question because I know they're usually flagged as unproductive - which language would be better for me (as someone inexperienced with socketing) to write a sufficiently efficient server - assume equal experience with both?
Lastly - if this is relevant - I have not begun development on the client - not sure what my goals for the game itself are yet, I just want the servers to be scalable (up to ~150 players, beyond that I expect and understand that major rewrite will probably be necessary) and able to support a fair amount of players and open-world style content. (no server-taxing physics or anything like that necessary)
"I assume that the majority of gameplay data (e.g. fine player
  movements) will need to be sent via UDP connections. I'm unfamiliar
  with UDP connections so I really don't know where to begin designing
  the server."

UDP can be lower latency, but sometimes, it is far more important that packets aren't dropped in a game.  If it makes any difference to you, World of Warcraft uses TCP.  If you chose to use UDP, you would have to implement something to handle dropped packets.  Otherwise, what happens if a player uses an important ability (Such as a spell interrupt or a heal) and the packet gets dropped?  You COULD use both UDP and TCP to communicate different things, but that adds a lot of complexity.  WoW uses only a single port for all gameplay traffic, plus a UDP port for the in-game voice chat that nobody actually uses.

"How should the server be threaded? One thread per client connection that retains session info, and then a separate thread(s) to control autonomous world changes (NPCs moving, etc.)?"

One thread per client connection can end up with a lot of threads, but would be a necessity if you use synchronous sockets.  I'm not really sure of the best answer for this.

"How should relatively large packets be transmitted? (e.g. ~25 nearby players and all of their gameplay data, usernames, etc.) TCP or UDP?"

This is what makes MMORPG servers so CPU and bandwidth intense.  Every action has to be relayed to potentially dozens of players, possibly hundreds if it scales that much.  This is more of a scaling issue than a TCP vs UDP issue.  To be honest, I wouldn't worry much about it unless your game catches on and it actually becomes an issue.

"Lastly - is it safe for the gameplay server to interface with the login server via HTTP requests, how do I verify (from the login server's perspective) the gameplay server's identity - simple password, encryption?"

You could easily use SSL.

"Lastly - if this is relevant - I have not begun development on the client - not sure what my goals for the game itself are yet, I just want the servers to be scalable (up to ~150 players, beyond that I expect and understand that major rewrite will probably be necessary) and able to support a fair amount of players and open-world style content. (no server-taxing physics or anything like that necessary)"

I wouldn't use Python for your server.  It is horrendously slow and won't scale well.  It's fine for web servers and applications where latency isn't too much of an issue, but for a real-time game server handling 100+ players, I'd imagine it would fall apart.  Java will work, but even THAT will run into scaling issues before a natively coded server does.  I'd use Java to rapidly prototype the game and get it working, then consider a rewrite in C/C++ to speed it up later.
Also, something to consider regarding Python...if you haven't read about the Global Interpreter Lock, I'd make sure to do that.  Because of the GIL, Python can be very ineffective at multithreading unless you're making calls to native libraries.  You can get around it with multiprocessing, but then you have to deal with the overhead of communication between processes.
Structuring a server for an online multiplayer game