SQL should allocate all available / configured memory, that is normal. (It may take a little while after startup, but "normal running state" is with all appropriate memory allocated.
As a broad-brush answer set SQL Max Memory usage to total installed memory LESS 4GB (to reserve that for O/S). In practice you probably should use a figure taking into account number of processors, and it might be that that level of finesse is no longer needed in SQL2012
My guess is that that has nothing, or very little, to do with your hardware and is caused by the queries not being optimised or there being no maintenance on the server / databases. e.g. indexes that would help do not exist, or the statistics are out of date, or the indexes have grown and become fragmented and have not being rebuilt/reorganised. Might also be that SHRINK has been used on the database regularly and that has badly fragmented the database.
I don't think that is "huge", but "it depends"; it is certainly "quite big". TEMPDB growing every day is not a good sign, but I would expect it to grow initially and then maintain that large size.
We create a TEMPDB of "sufficient size" taking care to ensure that the VLBs are kept to a minimum and optimised. if you go with the defaults you probably have a 10MB TEMPDB which grows in 10MB pieces and is horribly inefficient as a consequence. If your site needs a 60GB TEMPDB then make sure it is created initially at that size (i.e. when SQL Service starts)
That's not a good sign, but might be a symptom of some of the other issues.