The JSON file should be a bit smaller probably, but what's more important is the compressed size of your JSON file. I assume this will be running on a web server? If so, make sure that gzip is enabled when you transfer your files. The uncompressed JSON may be a few megabytes, but the compressed version is going to be a just a few kilobytes - a lot of the data in there is very repetitive, it's going to compress extremely well. I'd be surprised if it's ever more than 100KB when zipped.
The size, in memory, of each cell and tile is really small, it's just a few bytes. Even if you have lots of them, it's going to be a few megabytes of RAM. I'll make an example. Say that you use N different types of sprites for your tiles, internally wade.iso creates an array with N entries a bit like this:
[ {texture: 'myImage.png', size: .... }, {texture: 'myOtherImage.png', size: .... }, .....]
Then for each cell (or tile), it just stores the index into that array. So if you have 600x600 cells (360K cells) it's just going to be an array with 360K numbers in it, it isn't a big deal in terms of memory. It may take a while to load, but once loaded it should be fine.
The real problem may be the graphics... if you're using several different images, then that may be a problem, since each image may take up several kilobytes if not megabytes of RAM. In that case it may be worth loading only the images that are visible at any one time, and unloading the rest. But be aware that some browsers (mainly Safari) are terrible at unloading things, and tend to keep them in memory until they crash. Chrome, Firefox and even IE are much better in that respect.
But if you have a large map, and less than 100 megapixels for your sprites, I think you could load it all in one go and not worry about memory usage. This really depends on your target platforms, but most modern mobiles can cope with 100 megapixels of image data.
Like I said above, performance is an entirely different matter, but things that aren't visible won't be drawn, so wade.iso should be able to deal with lots and lots of objects provided that they aren't all visible at the same time.
As a personal suggestion (which isn't related to any technical issues), I would suggest that you try your game with fewer players first and then expand it. There are always issues with big numbers of players, mainly on the server side, and solving these issues costs money. I wouldn't spend lots of money on the server infrastructure unless I'm 100% sure that I'm going to hit my 5,000 players target. I'd start with maps for 100 players. But like I said, this is just a personal suggestion and feel free to ignore it :)