Adding second SQL Server to create 2 Node cluster I am not a dba. I have general knowledge of SQL Server and T-SQL. Our company currently has a SQL Server 2008 R2 hosting about 30 databases.

I've been asked to research adding a second server for HA/Failover. My question is, should I be considering upgrading the current server to at least 2012, and build the new server the same? I had initially thought about building another 2008 R2 server, but it looks like clustering and HA is much improved in 2012.

Also, not being an expert, is this going to be something a journeyman administrator can accomplish (obviously you can't gauge my skill level) or will we be looking at engaging a consultant? I know that question may be hard to answer.
Get us HA is often spoken by management but the clarity isn't there.  You'll want to first cover your butt to make sure you're both on the same page as what "HA" is.  First set acceptable data loss policies and acceptable downtime in case of an emergency.  Answer 1 will be 0 data loss and 0 seconds down time.  Great, 6 9's uptime will require their entire budget and then some.  Once they realize that they will decide that they can probably be down x minutes or hours per year.  They will also help you define 'maintenance hours' where you can have extended outages if possible.  

Once you know if you can have maint. hours and how much downtime is acceptable, you can pick an HA solution.  Remember that clustering shares storage, so you have 1 single point of failure.  It's probably not what you're looking for in this case.  You will probably want to do async mirroring which is sadly only available in enterprise.  If you don't have enterprise you will have to go with Sync. mirroring.  This requires your write to finish on the 2nd server before it calls it complete on the first server.  Unless you're monitoring the full stack and have a witness server for auto fail over, this will probably cause you more outage time where users can't write, than it'll save.  

The easiest and cheapest option is log shipping.  This doesn't allow you to auto failover like mirroring with a witness or clustering (albeit not with storage failure as the whole cluster goes down).  It is however easy to setup, maintain, and can ensure you're only 1 or 2 transaction log backups behind.  Then you can practice 'tail of log' backups and automate it if you still have access to the primary to get ALL the data out and bring up the secondary.

Come back with uptime/data loss reqs and we'll help you dig deeper if you need it.