In general for C# and specifically for Unity I would advise against it... but if you really wanted to, or had good reason, you could.
In C# you would need to familiarize yourself with what is called unsafe code. Scared yet?
In Unity you would need to enable unsafe compilation mode so you will not be able to use the web player if you planned on that. You can read more here or here.
So basically C# was designed with a Garbage Collector as many scripting languages are. The general idea is to try and abstract the notion of memory management to simplify development. You can still end up with resource leaks if you don't nullify your objects. I'm honestly not a huge supporter of GCs and would prefer RAII methods instead, but this is the world we live in.
Most C++ developers would also, however, agree that you shouldn't use pointers directly anyway and should prefer to use an RAII designed type aka smart pointers. If you are in C land then likely pointers are second nature to you, but even then it helps to abstract them to some degree.
If you do use them in C# just be aware that there is a very real potential you could add security vulnerabilities or really nasty and hard to track down bugs. You will also need to keep in mind that you must be careful not to reference objects that can be moved by the GC. Note the use of the fixed statement here.
You can also use Pointers in Unity by writing a native plugin. This again will rule out webplayer builds, but the new HTML5 feature works based on emscripten so if you planned on using that you likely could if you are careful. Native plugins allow you to extend Unity on a per platform basis. I wrote a native plugin to communicate with some microcontrollers via a serial connection for example.
So to summarize you should definitely ask yourself why do I want to use pointers in C# in Unity. If you just want to do it for fun... Knock yourself out.
Edit:
I'm sorry if I had offended anyone as I know my thoughts on GC are not of the popular opinion right now.
If you really read my answer you will note that I do not call C# a scripting language. I compare it to "many scripting languages", however, in the context of Unity it is very much so used as a scripting language. It is somewhat of a DSL to Unity if you will. Often times you will see it even referred to as Unity Script in this context (this is mostly in reference to Unity's Javascript alternative to C#). If you put LLVM in your pipeline you can just compile it to native code for the platform directly... then what would you call it? So really I didn't want to split hairs here.
Many great references to software engineering are filled with opinion:
Effective C++,
More Effective C++,
C++ FAQ,
Effective C#,
Modern C++ Design,
Design Patterns
...
And countless others. I don't feel this makes the arguments any less credible if they are followed by thoughtful explanation.
I was not really all out saying "Don't use pointers ever!!". In fact I still use them naked on occasion. I said "in general" as in "prefer using safe code to unsafe code in C#". There are situations where it can be beneficial, and that is one of the really powerful features of C# to pick and choose your tools. C# even allows you to have transparency in the GC process to some degree, languages like Dart do not and can lead to resource leaks very easily. Sure if you are the sole developer of a small project it isn't likely a problem. If you are on a team of say 10+ with hundreds of thousands of lines of code then it can get tricky.
I simply wanted the reader to exercise caution when using naked pointers. It is akin to saying be very careful when working with mains electricity. I'm not saying don't be an electrician, just that if you make the wrong move and don't treat it with respect you are dead.
I do like the example given by Lasse in which performance may have dictated the need.