In an MMOG, "concurrency" refers to how many players are online at the same time. For games with multiple servers/shards/realms, this number is typically for a single server rather than across all servers the game operates. (Technically a "server" is a single machine in a cluster of other networked servers that together comprise a single instance of the entire game state, but I'm going to use it in the more common sense of a server cluster/shard/realm.)
Concurrency is a big concept for MMOGs. If few people are playing on a given server, it's probably a dull place to be - you can't find people to group with, the auction houses have little to offer, and so on. And if the MMOG requires high concurrency to make major systems work, such as crafting or a dynamic economy, then a low-concurrency system may mean the game is simply broken on that server.
Game companies love to tout their concurrency as evidence of their games' success. EVE Online has made a habit of trumpeting their latest concurrency records, only recently tallying 54,446 simultaneous players on one server. Second Life once charted almost 90,000 across its archipelago. Conversely, games that never talk about their concurrency probably avoid the topic for obvious reasons.
It's arguable, however, that concurrency is a bit of a sham. Or to put it another way, if I die alone in a dungeon on a server with 30,000 concurrent players, am I really playing an MMOG? If you go to MMOG developer conferences like Austin GDC, you'll hear MMOG server devs explain that massive concurrency on a single server isn't really a hard problem these days. Every game could be EVE Online or Second Life in this regard. The real challenge is game design and content: if 90,000 players entered a newbie zone in World of Warcraft, the game would be unplayable. That wouldn't be so much a failing of server technology as it would be of not having enough terrain and content for so many players at once. If EVE Online had 54,446 players in the same system, it'd be unplayable too. Indeed, back in the heyday of Dark Age of Camelot's PvP keep battles, a known exploit was to get 100+ defenders on your side to crash the server and thwart the assault.
I think we should be talking about something other than concurrency. The real measure of a large-scale multiplayer experience should be described as proximal concurrency: how many other players are interacting with the same game data as you? (Such as: attacking the same monster.) This doesn't mean they have to be standing in the same general location as you, although that's a valid example. They could also be interacting with the same system. If an MMOG had an eBay-style live auction system, for example, and 20,000 players were bidding on the same rare item at the same time, that would be a proximal concurrency of 20,000.
In current games, proximal concurrency tends to be very, very low compared to server concurrency. This is usually because our notion of proximal concurrency is very location-based. 200 players moving around in the same location would cause so many movement updates to be passed between the server and all the players that performance would drag to a halt, at least on the players' computers; their bandwidth would just choke on that many movement updates.