Update: Now that temp drives are available as SSDs for D-Series Azure VMs, the whitepaper cited by @CSharpRocks is slightly out of date. See the following two articles for more recent recommendations (as of late-2014 through mid-2015):

• Performance Best Practices for SQL Server in Azure Virtual Machines (April 2015)
• Using SSDs in Azure VMs to store SQL Server TempDB and Buffer Pool Extensions (September 2014)

The articles above explicitly mention placing tempdb and Buffer Pool Extensions on D:. Excerpt:
Only store tempdb and/or Buffer Pool Extensions on the D drive when using the D-Series Virtual Machines (VMs). Unlike the other VM series, the D drive in the D-Series VMs is SSD-based. This can improve the performance of workloads that heavily use temporary objects or that have working sets which don't fit in memory.

There's some confusion about this since the original recommendation was to place tempdb on the D: drive. This is no longer true. For the latest info, I recommend that you read the "Performance Guidance for SQL Server in Windows Azure Virtual Machine" whitepaper located here: http://msdn.microsoft.com/en-us/library/windowsazure/dn248436.aspx

Here's an extract with the TempDB section:

As mentioned in section Windows Azure virtual machine disks and cache settings, we recommend that you place tempDB on the operating system disk or the data disk instead of the temporary disk (D:). Following are the three primary reasons for this recommendation based on our internal testing with SQL Server test workloads.

• Performance variance: In our testing, we noticed that you can get the same level of performance you get on D:, if not more IOPS from the operating system or a single data disk. However, the performance of D: drive is not guaranteed to be as predictable as the operating system or data disk. This is because the size of the D: drive and the performance you get from it depends on the size of the virtual machine you use.

• Configuration upon VM downtime situation: If the virtual machine gets shutdown down (due to planned or unplanned reasons), in order for SQL Server to recreate the tempDB under the D: drive, the service account under which SQL Server service is started needs to have local administrator privileges. In addition, the common practice with on-premises SQL deployments is to keep database and log files (including tempDB) in a separate folder, in which case the folder needs to be created before SQL Server starts. For most customers, this extra re-configuration overhead is not worth the return.

• Performance bottleneck: If you place tempdb on D: drive and your application workloads use tempDB heavily, this can cause performance bottleneck because the D: drive can introduce constraints in terms of IOPS throughput. Instead, place tempDB on the operating system or data disks to gain more flexibility. For more information on configuration best practices for optimizing tempdb, see Compilation of SQL Server TempDB IO Best Practices.

For 2017:

I have a long running stored procedure that is tempdb intensive. Setting up Tempdb on the OS drive, as Azure configured it by default, on a DSv2 machine using SDD disks, the query ran at about 1 and a half minutes.

Moving the Tempdb to the temporary storage (and doing nothing else) changed the query to run in 57 seconds, so about a 33% improvement in performance. The query was run repeatedly in both cases and the timing was (give or take) consistently at those numbers.

Putting the TempDB on temporary storage requires special consideration in terms of starting SQL server. There are two approaches. One is to point the files to the root of D and give the SQL server process local administration permissions. This is the scenario you want to consider if you already have something else starting the SQL Server process rather than just an automatic service startup. Otherwise it raises security eyebrows.

The second option is to set the SQL Server service to manual startup, and then write a powershell script to launch it, and put that powershell script on a scheduled task to run at startup. The powershell script would first ensure that the directory exists on the temporary storage before starting SQL server.

It has already been linked to in another answer, but this document is updated as of 2017 and it does not formally recommend this kind of setup for TempDb, rather just moving it off of the OS partition. However, it says:
If your workload makes heavy use of TempDB (e.g. for temporary objects or complex joins), storing TempDB on the D drive could result in higher TempDB throughput and lower TempDB latency.

My performance experience confirmed that last line.

Sorry posting to an old thread...but just saying this in case someone else hits this. You can store tempdb files on azure temp disk (D:) on azure VMs. BUT, put them in root and dont path them. when it clears the paths go too and SQL service wont start because it cant find the paths. So put them in D:\ root.