Thanks for your effort. I remember too that inodes simply does not exists on win. Can that number be something derived from Master File Table? i'm guessing only.
Anyway the number are consistent, more: they are consistent even for hard links, and using stat (maybe next hour inspecting stat.c ;=)..):

>touch test02.txt

>C:\SCRIPTS\GnuWin32-bis\bin\ls.exe -il test02.txt
12666373953464529 -rw-rw-rw-  1 lt 0 0 2014-11-13 11:26 test02.txt

>C:\SCRIPTS\GnuWin32-bis\bin\ln test02.txt link-to-test02.txt

>C:\SCRIPTS\GnuWin32-bis\bin\ls.exe -il test02.txt link-to-test02.txt
12666373953464529 -rw-rw-rw-  2 lt 0 0 2014-11-13 11:26 link-to-test02
+.txt
12666373953464529 -rw-rw-rw-  2 lt 0 0 2014-11-13 11:26 test02.txt

>echo Perl > test02.txt

>cat test02.txt
Perl

>cat link-to-test02.txt
Perl

>C:\SCRIPTS\GnuWin32-bis\bin\ls.exe -il test02.txt link-to-test02.txt
12666373953464529 -rw-rw-rw-  2 lt 0 7 2014-11-13 11:28 link-to-test02
+.txt
12666373953464529 -rw-rw-rw-  2 lt 0 7 2014-11-13 11:28 test02.txt

>C:\SCRIPTS\GnuWin32-bis\bin\stat -c "%i %N"  test02.txt
12666373953464529 `test02.txt'

>C:\SCRIPTS\GnuWin32-bis\bin\stat -c "%i %N\n" link-to-test02.txt
12666373953464529 `link-to-test02.txt'
[download]

L*
UPDATE: they state explicitely here:
st_ino Number of the information node (the inode) for the file (UNIX-specific). On UNIX file systems, the inode describes the file date and time stamps, permissions, and content. When files are hard-linked to one another, they share the same inode. The inode, and therefore st_ino, has no meaning in the FAT, HPFS, or NTFS file systems.

L*
UPDATE BIS:

C:\Windows\system32>fsutil file queryfileid c:\SCRIPTS\test02.txt
ID del file: 0x002d00000016a8d1


C:\Windows\system32>fsutil file  queryfilenamebyid c:\ 0x002d00000016a
+8d1
Nome collegamento causale al file: \\?\C:\SCRIPTS\test02.txt

#0x002d00000016a8d1 hex is equal to 12666373953464529 dec (the same nu
+mber as above!!!)
[download]

L*